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 a key side effect: the received token is saved locally to ~/.globus-mcp/state.json. It does not mention overwrite behavior, failure handling, or session validity, but the file-path disclosure is concrete and valuable beyond the schema.

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

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

The description is two tight clauses with no filler: it states the action and the local persistence effect. Both sentences earn their place, and the action 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?

For a 2-parameter login tool with no annotations, the description covers the main action and side effect, and an output schema exists so return values are not a gap. It is still incomplete because it does not explicate the optional phone parameter or the dependency on a preceding auth_send_code step, leaving an agent to infer part of the call sequence.

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 parameters. It clarifies that 'code' is the SMS confirmation code, but it says nothing about the optional 'phone' parameter or why/when it should be provided. Only half of the parameter space is addressed.

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 resource: 'Подтвердить вход кодом из SMS' (confirm login with an SMS code), which clearly distinguishes it from siblings like auth_send_code that issue the code and auth_set_token that sets a token manually. The core purpose is immediately understandable.

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 'кодом из SMS' and the presence of sibling auth_send_code establish the intended sequence: use this after a code has been sent. However, there is no explicit 'use this after auth_send_code' or 'not when token already exists' guidance or exclusions, so it falls short of fully explicit routing.

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?

There are no annotations, so the description must carry the behavioral disclosure. It does state the main side effect (token forgotten, session becomes anonymous), but it does not explain whether the token is invalidated server-side, whether the action is reversible, or what happens if no token is stored.

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 with no filler. The core action and its consequence are front-loaded and immediately understandable.

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 logout tool with an output schema, the description captures the purpose and the resulting session state. It could additionally clarify behavior when no token exists, but that is not essential for successful invocation.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation burden exists.

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

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

The description uses a specific verb ('забыть' / forget) and a concrete resource ('сохранённый токен' / saved token), and additionally states the outcome (session becomes anonymous). This clearly distinguishes it from siblings like auth_set_token and auth_login.

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 usage context is implied: call this when the user wants to log out or clear the saved token so the session becomes anonymous. However, it does not explicitly state when not to use it or mention alternatives, so guidance is only implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the side-effecting behavior (sending an SMS) and the required phone format, which is useful. However, it does not mention potential rate limits, code expiration, idempotency, or whether the phone must already be registered, leaving some behavioral gaps.

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

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

The description is extremely concise: two short sentences, with the core action and format front-loaded and the login-step context following. Every word earns its place, and there is no redundant information.

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

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

Given the low complexity (one required parameter, no nested objects, and an existing output schema), the description is nearly complete. It provides the purpose, phone format, and step context. A brief note about prerequisites or behavior on invalid phones would push it to a 5, but nothing essential is missing for basic 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%, so the description must compensate for the undocumented phone parameter. It adds the expected format '79161234567', which is genuinely valuable and goes beyond the bare schema. For a single obvious parameter, this is sufficient semantic guidance.

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

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

The description uses a specific verb and resource: 'Отправить SMS-код на телефон' clearly states the action and target. It also provides the expected phone format and positions itself as the first step of login, which distinguishes it from sibling tools like auth_login and auth_set_token.

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

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

The description gives clear usage context by stating this is the first step of login, implying it should be used before auth_login. However, it does not explicitly mention when not to use this tool or name an alternative, though the 'first step' framing is fairly directional.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does explain that the tool imports a JWT directly and describes where the token comes from, but it does not mention potential side effects such as overwriting an existing session, whether the token is validated, or what happens after the token is set.

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 short and front-loaded: the main action comes first, followed by the source and the specific use-case. Every sentence provides useful information with no filler.

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

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

For a tool with a single required string parameter and an output schema, the description is largely complete: it tells the agent what the token is, where to get it, and when to use the tool. It could add a note about whether the tool replaces an existing authenticated session, but this is a minor gap given the low complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It adds substantial meaning by identifying the token parameter as a JWT and specifying the exact browser source (__NEXT_DATA__.props.pageProps.token), which goes beyond the schema's generic 'token' property.

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

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

The description uses a specific verb 'Импортировать' and a clear resource 'JWT', and even names the source location in the browser. This clearly distinguishes it from siblings like auth_send_code, auth_login, and auth_logout, and the mention of a workaround further differentiates it from the normal SMS flow.

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 explicitly states when to use this tool: as a fallback if SMS login did not work ('Обходной путь, если SMS-логин не отработал'). This gives an agent a concrete trigger and implies the alternative normal flow is SMS-based authentication.

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 are absent, so the description carries the full burden of behavioral disclosure. It states the core mutation, but does not explain whether repeated adds increment quantity or create duplicate line items, whether an existing cart or auth token is required, or what side effects occur. This is a meaningful transparency gap 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?

The description is a single, short sentence with no filler and the core action is front-loaded. It is appropriately terse for a simple tool, though it omits parameter and usage details that could be added without much bloat.

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 low-complexity tool with an output schema present, the description covers the basic action. However, it omits the relationship to sibling cart tools, does not state authentication requirements, and leaves parameter semantics entirely to the schema. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, and the description does not mention product_id or quantity at all. The input schema only provides field names and types, leaving the agent without guidance on how to resolve product_id or how quantity behaves. The description fails to compensate for the low coverage.

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

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

The description uses a clear verb ('Добавить') and identifies the resource (a product added to the existing cart). The phrase 'already lies in the cart' signals additive semantics that help differentiate it from cart_set_quantity or cart_clear, though it stops short of explicitly naming those alternatives.

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

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

The description implies the tool is for adding to an existing cart, but it gives no explicit guidance on when to choose cart_add over cart_set_quantity or cart_clear. It also does not mention prerequisites such as authentication or an existing cart. Usage context is implied rather than stated.

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

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

With no annotations, the description carries the behavioral burden. It clearly communicates that the operation removes all items, which is the main side effect, but it does not explicitly warn that this is an irreversible or destructive operation or describe any confirmation behavior.

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

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

The description is a single short sentence with no filler. It front-loads the action and scope in six words and earns its place entirely.

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, simple cart operation with an output schema available, the description is largely sufficient. The only missing context is an explicit irreversibility warning or an alternative routing note, but these are not critical for such a minimal tool.

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

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

The input schema has zero parameters and 100% schema description coverage by default, so the description carries no parameter-documentation burden. The baseline of 4 applies because there are no parameters to explain.

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 precise action ('Убрать' / remove) and a precise resource ('из корзины все товары' / all items from the cart). The word 'все' distinguishes it from partial cart operations like cart_set_quantity, making the tool's scope 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 use case is implied: an agent can infer to call this when the entire cart should be emptied. However, there is no explicit guidance about when not to use it or that cart_set_quantity should be used for removing a single item.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals two non-obvious behaviors: quantity=0 deletes the product, and for weighted goods the step is defined by basket_step in the product card. This goes beyond the tool name and schema.

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 concise sentences, front-loaded with the main purpose followed by important edge-case behavior. Every sentence earns its place with no filler.

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

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

Given only two parameters, an output schema, and no annotations, the description covers the essential behavior: setting quantity, removing via zero, and weighted-item stepping. It could additionally mention auth or cart-existence requirements, but those are not critical for this straightforward mutation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the quantity parameter, including the zero-removal behavior and weighted-goods step rule. product_id is left self-explanatory, but the description still adds value beyond the raw schema.

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

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

The description states a specific verb ('Задать') and a specific resource ('количество товара в корзине'), clearly distinguishing this tool from cart_add, cart_clear, and cart_view. It is unambiguous about what the tool does.

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

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

The description gives clear context: use it to set the quantity of a cart item, and explicitly states that quantity=0 removes the item. It does not explicitly name alternatives or exclusions, but the usage context is sufficiently clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. The phrasing 'contents of the cart' implies a read-only snapshot and no side effects, which is the key trait, but it does not explicitly state that the cart is unmodified, nor does it mention authentication or data freshness. This is adequate but leaves room for explicit confirmation.

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

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

The description is a single short phrase that delivers the essential content and totals semantics with no filler. Every word contributes, and the core purpose is front-loaded before the currency qualifier.

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

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

For a parameterless view with an output schema, the description covers the main information an agent needs: what is returned (contents and totals) and the currency. It could be slightly more complete by explicitly framing itself as a read-only cart view and pointing to when checkout_info might be more appropriate, but nothing critical 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?

The input schema has zero parameters and 100% schema description coverage, so there is no parameter vocabulary for the description to enrich. The only parameter-like detail, 'prices in rubles', usefully specifies the currency unit of the returned totals. A baseline of 4 is appropriate for a 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?

The description identifies the resource ('cart') and what is returned (contents and totals in rubles), which clearly positions it as a read operation distinct from sibling cart mutations like cart_add, cart_set_quantity, and cart_clear. However, it is a noun phrase rather than an explicit verb+resource statement, and it does not name the alternatives it differs from.

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

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

No guidance is provided on when to call cart_view versus other cart-related or checkout tools. The description neither states conditions, prerequisites, nor exclusions, so an agent must infer usage entirely from the tool name and siblings.

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 behavioral burden. It discloses the encoded output format ('<filter id>:<value id>') and how the output is consumed, which is useful. It does not mention behaviors like empty results, limit handling, or error conditions, but the disclosed format is a meaningful behavioral detail.

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

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

The description is two short sentences with no filler. It front-loads the purpose and immediately follows with the essential output format and integration instruction, so every sentence earns its place.

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

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

For a simple two-parameter tool, the description covers the core purpose and the key integration detail for category_products. However, values_limit is undocumented and usage timing is only implied, leaving moderate gaps despite an output schema being 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 description coverage is 0%, so the description must explain parameters, but it only implies category_id through 'категории' and never mentions values_limit or how it affects results. The output format is explained, but parameter meaning is largely left to the bare schema.

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

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

The description states that the tool returns available filters for a category, which is a specific resource and purpose, and it is clearly distinct from siblings like category_products or list_categories. It lacks an explicit verb like 'get' or 'list', but the noun-phrase 'available filters' plus the format explanation make the purpose clear.

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 practical guidance: the returned strings should be passed into the filters argument of category_products. It implies when to use the tool (before filtering category products) but does not explicitly state when not to use it or name alternatives.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains the filter format and the special flag-filter meaning (e.g., '2147483644:да' means only discounted products), which is useful. It does not mention pagination, sorting behavior, or whether the call is read-only, but the output schema partially covers expected results.

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 compact and front-loads the purpose, then gives source guidance and filter details. Every sentence contributes useful information, and the filter examples are formatted clearly. It could be slightly more explicit about the action, but it is well organized.

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

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

The description covers the required parameters and the most complex parameter (filters), which is the main contextual risk. It does not describe accepted sort values or pagination behavior, though the schema provides defaults. Given six parameters and no annotations, it is adequate but leaves some 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?

Schema description coverage is 0%, so the description must add meaning, and it does for the non-obvious parameters. It explains the exact 'filter_id:value_id' string format for filters and gives concrete examples, including flag filters. The remaining parameters (page, sort, per_page) are sufficiently self-explanatory from 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 identifies the resource as 'Товары категории' (category products) and explains that category_url and category_id come from list_categories or search_products.categories. This makes the tool's purpose clear and connects it to sibling tools, though it lacks an explicit verb like 'get' or '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 description implies when to use the tool: after retrieving category identifiers from list_categories or search_products.categories, and with filters from category_filters. However, it does not explicitly contrast this tool with search_products or state when one should be preferred over the other.

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 transparency burden and does it well: it discloses the authorization requirement, confirms the tool is non-mutating, and explains that it returns a summarized digest rather than raw output. It also warns about sensitive personal data and advises against dumping the full result into the model context, which is valuable behavioral guidance beyond any structured metadata.

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 compact and well-structured: it leads with the tool's purpose, then adds preconditions, side-effect clarification, and a practical output-handling warning. Every sentence contributes meaningful information with no 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 zero-parameter tool with an output schema, the description covers the essential operational context: what data is returned, authorization requirements, the fact that no order is placed, and how to handle the sensitive response. Nothing critical is missing for an agent to invoke this 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 has zero parameters, and the schema confirms no arguments are needed, so there is no parameter semantics gap. The description appropriately focuses on what the tool returns instead of trying to document nonexistent parameters.

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

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

The description clearly identifies the tool as providing checkout data: recipient, addresses, delivery slots, and totals. It also explicitly states 'Заказ не оформляет' (does not place an order), which distinguishes it from order-placing actions, though it lacks a direct verb like 'retrieves' and does not name a specific sibling for contrast.

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 states a necessary precondition ('Требует авторизации') and an explicit exclusion ('Заказ не оформляет'), giving the agent a clear sense of when this tool is appropriate for viewing checkout info. It does not explicitly mention alternatives or when-not-to-use beyond not placing an order, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only CMS page lookup but does not confirm side effects, authentication needs, error behavior, or how the 'arbitrary' page resolution works.

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

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

The description is two compact sentences with no wasted words. It front-loads the core behavior and then gives usage context, which is ideal for quick agent scanning.

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 getter with an output schema, the description covers the main purpose, parameter semantics, and usage context. However, without annotations and with limited behavioral detail, it is not fully self-sufficient for an agent deciding whether this is the right tool and how safely it can be called.

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 only parameter is a plain string titled 'Code'. The description adds meaning by explaining that the code identifies a CMS page and gives examples, but it stops short of specifying accepted formats or a full allowed value list.

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

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

The description clearly identifies the resource (arbitrary CMS page) and the access mechanism (by code), with concrete examples like divorce_shares and main. It lacks an explicit verb such as 'get' or 'fetch', but the meaning is still unambiguous in context.

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

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

The phrase 'Полезно для подборок и лендингов' provides useful usage context for collections and landing pages. However, it does not explicitly state when not to use this tool or how it compares to the many sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey that the tool reports current state rather than changing it, and it lists the specific session attributes returned. However, it does not explicitly state that the tool has no side effects, does not require authentication, or has any rate or access 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 a single, compact sentence that front-loads the primary concept ('current session state') and immediately enumerates the useful details. There is no filler, repetition, or unnecessary elaboration.

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 tool with an output schema present, the description adequately covers the key information an agent needs: authorization status, store/purchase method, and device identifier. It does not explain return formatting, but the output schema already exists to fill that gap.

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

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

The tool has zero parameters, and the schema coverage is effectively complete, so parameter description is not needed. The description correctly focuses on what the session status contains rather than trying to document nonexistent parameters.

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

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

The description clearly states that the tool reports the current session state, specifically whether the user is authorized, which store/delivery method is selected, and the device identifier. This is a specific resource ('session status') with clear scope. It does not explicitly contrast itself with sibling auth_* tools, but the read-only status nature is evident from the wording.

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

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

The description gives no explicit guidance about when to call this tool versus alternatives such as auth_login, auth_logout, or set_purchase_method. It implies a read-only status check, but does not state that this is the tool to call when the agent needs to know the current authorization or purchase-method context before proceeding.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the output scope ('top level and subcategories') and does not explain how the with_children parameter changes that scope. It conveys a read-only listing resource, yet leaves parameter-dependent behavior and response details to be inferred from the schema and output schema.

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 definition is a single, brief sentence with no redundancy, naming the resource and its two relevant levels. It is efficiently structured, though it could have included parameter guidance without much added length.

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 tool with one optional parameter and an existing output schema, the description is minimally viable, but it omits the effect of with_children and provides no explicit usage boundaries against sibling category tools. The output schema covers return shape, yet the lack of parameter guidance and usage context leaves a small but real gap.

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

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

Schema description coverage is 0%, and the description never mentions the only parameter, with_children. The parameter name and default are self-evident from the schema, but the tool description adds no explicit meaning about how the boolean affects the returned catalog tree.

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 identifies the resource as the catalog tree and specifies its content: top-level categories and subcategories. It lacks an explicit verb, relying on the tool name, and does not directly contrast with sibling tools like category_products, so it is clear but not fully differentiating.

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

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

The description implies that this tool is for retrieving hierarchical category data, but it gives no explicit guidance about when to use it instead of category_products or category_filters. There are no exclusions or alternative routing clues, so applicability must be inferred from the tool name and the phrase 'catalog tree.'

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that query filters by name/address. It does not reveal whether the operation is read-only, whether omitting query returns all pickup points, what happens when no results match, or any auth requirements. These gaps are significant for an agent with no annotation fallback.

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

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

The description is a single compact sentence with no wasted words. It front-loads the most important information (what the tool is) and then adds parameter semantics. This is appropriately concise and well-structured.

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

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

The tool is simple (one optional parameter) and an output schema exists, so return values need not be spelled out. However, the description is missing explicit usage context and behavioral guarantees (e.g., read-only, returns all when query is null). An agent has to infer too much about when and how to call it correctly.

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

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

The schema has no description for the 'query' property (0% coverage), so the description's note that it filters by name/address adds genuine semantic value. It is brief but sufficient to convey that query is a free-text search filter. It could mention matching behavior (e.g., substring or case-insensitivity), but this is a minor omission for an optional parameter.

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

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

The description identifies the resource ('Пункты выдачи заказов (ПВЗ)') and, combined with the tool name 'list_pickup_points', makes it clear the tool lists order pickup points. It distinguishes from the sibling 'list_stores' by naming pickup points explicitly. However, it lacks an explicit verb and does not state the scope (e.g., returns all pickup points or only those for the current order).

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

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

There is no guidance on when to use this tool versus alternatives such as list_stores or search_products. No context is given about prerequisites like an active cart/order, whether this is for checkout selection, or any conditions that would make a different sibling more appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the query parameter filters by name/address, but it does not state that the tool returns a list of stores, whether authentication is required, or any limitations. The disclosure is too thin for an agent to fully anticipate tool behavior.

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

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

The description is very compact, front-loads the resource identity, and includes only relevant information about the parameter. Every phrase earns its place, and there is no verbose padding.

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 list tool with one optional parameter and an output schema present, the basic invocation is covered. However, the absence of usage guidance and any mention of authentication or alternative tool routing leaves the description incomplete for confident selection in a broader toolset.

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

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

The schema provides no descriptions for the 'query' parameter (0% coverage), so the description meaningfully compensates by explaining that query filters by name/address. This adds real semantic value beyond the bare schema definition, though it lacks examples or details about null handling.

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 identifies the resource (ГЛОБУС hypermarkets) and the query filtering behavior, making the tool's basic purpose clear. It does not contain an explicit verb like 'returns' or 'lists', but the tool name 'list_stores' plus the resource phrase conveys the intent. It also distinguishes from the sibling 'list_pickup_points' by explicitly naming hypermarkets.

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 about when to use this tool versus alternatives such as list_pickup_points, nor any mention of prerequisites or exclusions. The only behavioral clue is the query filter, but no context is given about typical use cases or selection criteria.

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

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

No annotations are provided, so the description carries the burden of conveying behavior. It implies a read-only product lookup through 'детальная карточка товара' and restricts the accepted input format. However, it does not mention authentication requirements, error behavior, or what happens for invalid or unavailable products; these are gaps, but the simple read semantics and output schema mitigate them.

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, information-dense sentence. Every part is useful: the tool's purpose, the parameter meaning, the expected format, and the source of the value. No wasted words.

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

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

Given a single required parameter and an existing output schema, the description covers the essential input semantics and provenance. The only notable omissions are explicit usage boundaries and behavior for invalid inputs, which are not critical for a simple product-details lookup.

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 description fully compensates. It explains that product_url can be a link or a slug, provides a concrete example (moloko-parmalat-35-1l-26730_ST), and tells the agent exactly where to obtain the value: the url field in search results.

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

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

The description clearly identifies the tool as a detailed product card and defines its key input, product_url. It is easy to distinguish from search-related siblings by meaning, though it uses a noun phrase rather than an explicit verb and does not explicitly contrast with alternatives.

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

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

The description gives clear contextual guidance: product_url should be taken from the url field in search results, which implies a search-then-details workflow. It does not mention when not to use the tool or name alternative tools, so it stops short of a perfect score.

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 states the content (active promotions, collections, catalog links) but does not disclose whether the operation is read-only, requires authentication, or how results are returned. For a tool with no side-effect annotations, some explicit behavioral context is missing.

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

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

The description is a single concise sentence that communicates the core subject and the associated output format (links to catalog). It is efficiently sized for a zero-parameter tool, though it leaves some behavioral and usage context unstated.

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

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

For a simple zero-parameter tool with an output schema, the description is minimally adequate: it names the resource and hints at response contents. However, it does not explain how 'promotions' differ from 'collections', whether results are filtered by store, or what an agent should do with the catalog links. Given no annotations and no usage guidance, the completeness is moderate.

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

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

The tool has zero parameters and the schema is fully covered by the empty properties object. With no parameters to describe, the description does not need to add parameter-level semantics; the baseline of 4 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 identifies the resource as active promotions and collections, and mentions catalog links, making the tool's purpose reasonably clear. It lacks an explicit verb like 'get' or 'returns', but the noun-phrase style still conveys what the tool provides. It is distinguishable from sibling tools such as recommendations and category_products, though not by name.

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 about when to use this tool instead of siblings like recommendations or category_products. The description implies it is for showing current promotions and collections, but gives no context, prerequisites, or exclusions.

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 disclosure burden. It does reveal the auth requirement for history-type tapes and the product_id dependency for combo_tape. However, it does not state what happens when product_id is missing for combo, how unauthorized sessions are handled, or whether the operation is read-only.

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

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

The description is a single compact sentence that front-loads the main resource and then efficiently lists all variants and their constraints. There is no redundant filler, and every clause adds actionable 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?

Given the tool's modest complexity and the presence of an output schema, the main gaps are around edge-case behavior: what happens with missing product_id, unauthenticated sessions, and whether the tool has side effects. The description covers the happy paths for all five blocks but leaves error/fallback behavior implicit.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by mapping the enum values to human-readable tape descriptions and by explaining product_id's role for combo_tape. Yet it never mentions the parameter name 'block' explicitly and does not explain behavior when product_id is provided for non-combo blocks or omitted for combo_tape.

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 identifies the resource as product feeds/ribbons and enumerates five concrete variants (popular, recommendations, combo, previously bought, viewed). It lacks an explicit verb like 'returns' or 'fetches', but the intent is clear. It also distinguishes itself from siblings like promotions or search_products by focusing on recommendation tape types.

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 meaningful selection criteria: combo_tape requires a product_id, and already_bought_tape and viewed_products_tape require an authorized session. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the conditions for picking the right block are clearly 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, but it only lists sort modes. It does not disclose pagination behavior, effect of the default sort, result shape, or any other operational traits beyond 'search products'.

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 compact and the sort list is front-loaded, but it is under-specified rather than efficiently complete. The first clause largely restates the tool name, so not every sentence earns its place.

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

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

An output schema exists, so return values are covered, but the tool has four parameters, no annotations, and no usage context. An agent cannot tell from this description how to construct an effective search or when this tool is preferable to sibling search/category tools.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the allowed sort values (default, price_asc, etc.), which is useful, but it leaves query, page, and per_page semantics entirely undefined.

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

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

The description clearly states the operation as product search ('Поиск товаров') and adds a sort-value list, so an agent can tell this is a product search tool. However, it does not differentiate it from sibling tools like search_suggest or category_products.

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 choose search_products over alternatives, no query-construction advice, and no mention of supported scenarios or exclusions. The description only states the resource and sort options.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists what kinds of suggestions are returned but does not state whether the operation is read-only, whether authentication is required, or how an empty query is handled. The description is a noun phrase with no behavioral context beyond output content.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It enumerates the output categories in a compact list, making it efficient and easy to scan. For a simple tool, this is appropriately concise and well structured.

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

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

The two-parameter tool has an output schema, so return structure is covered. However, the description leaves gaps: it does not explicitly instruct the agent to pass a user's search query, does not mention the optional limit in prose, and provides no usage context. It is minimally adequate but lacks behavioral and usage details.

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

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

Schema description coverage is 0%, and the description does not elaborate on the query or limit parameters. 'Query variants' hints that query is the search input, but there is no explicit explanation of what limit does or how it interacts with the result count. With low schema coverage, the description does not compensate by adding parameter meaning.

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

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

The description clearly states the tool provides search suggestions consisting of query variants, brands, categories, and top products, which is a specific resource and purpose. It distinguishes itself from related siblings such as search_products and list_categories by naming these output types. However, it lacks an explicit verb and does not directly contrast itself with sibling tools, so it does not earn 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 guidance on when to use this tool versus alternatives like search_products or recommendations. The intended context (e.g., autocomplete suggestions from a user's search query) is only implied by the tool name and the content list, never explicitly stated. No exclusions or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses an important behavioral consequence—'Цены и наличие зависят от него'—but does not explicitly state that the tool mutates the current cart/order state, whether authentication is required, or what happens if an ID is missing/invalid. Some behavior is described, but significant gaps remain.

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 compact and front-loaded: a one-line purpose sentence followed by a bullet-style breakdown of the three options. Every sentence carries information, and the formatting makes the parameter-to-method mapping easy to scan.

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 moderately complex setter with an output schema, the description covers the method choices, their required parameters, and where those parameters come from. It leaves out explicit error/authorization behavior, but the agent has enough to select the tool and construct a valid call.

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 maps each enum value to the relevant optional ID parameter and its source (e.g., 'pickup_store — самовывоз из гипермаркета (нужен store_id из list_stores)'). This adds real meaning beyond the raw schema, though it could be more explicit about leaving unrelated IDs null.

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

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

Description states a specific action ('Выбрать способ получения и точку') and immediately names the three allowed methods. The enum values are explained in plain language, making it clear the tool sets the purchase fulfillment method, distinct from list_stores/list_pickup_points which are data sources.

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?

For each method the description states which parameter is required and where to obtain it: store_id from list_stores, address_id from profile, pvz_id from list_pickup_points. This gives an agent explicit when-to-call and how-to-prepare instructions, with the alternatives named.

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