parsee

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 core mutation (adds to an existing group) and a non-obvious behavior (section is determined by group name). However, it does not mention duplicate handling, append vs. replace semantics, or what happens when the group does not exist. These gaps are notable but not fatal.

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 tight: three sentences, main action first, then the inference behavior, then mode-specific payload guidance. Every sentence contributes. The only minor issue is the unexpanded abbreviation 'СПП', which may confuse agents outside the domain.

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 no annotations and four parameters, the description is reasonably complete for common use: it explains pairs for compare, items for SPP and monitoring, and section inference. However, it does not specify the exact container format for monitoring items, behavior for missing groups, or mutation side effects. The presence of an output schema covers return values, so no penalty is applied there.

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 for the key parameters. It gives concrete shapes for pairs and items in different modes, which the bare schema does not provide. The section parameter's exact role and override behavior remain unclear, but the enum and the group-name inference rule give some 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 opens with a specific verb and resource: 'Добавляет позиции в существующую группу' (adds items to an existing group). This clearly distinguishes the tool from siblings like parsee_create_group, parsee_delete_group, and parsee_remove_from_group. The term 'позиции' is slightly vague, keeping it from 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?

The description gives explicit mode-based usage guidance: for comparison pass pairs as [{mine, rival}], for SPP pass items as [{url, sent}], and for monitoring pass links or article numbers. It also states that the section is inferred from the group name, which helps the agent decide how much to rely on the section parameter. It does not explicitly name alternative tools, but the operation itself is 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?

There are no annotations, so the description carries full behavioral burden. It discloses that the output contains only search-result cards with links, no product details, and warns against drawing market conclusions from a single search. It also exposes the shared-browser constraint requiring one query at a time.

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 front-loaded with the core purpose and then adds necessary constraints and caveats in a logical order. Every sentence adds value: scope, limitations, alternative tool, concurrency rule, and query-quality guidance.

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

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

The description covers purpose, output limitations, the proper downstream tool, and operational constraints. The only notable gap is the undefined limit parameter; the existing output schema covers return-value expectations, so that part is not missing.

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

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

Schema description coverage is 0%, so the description must compensate. It gives useful guidance for the query parameter (specific queries work, general ones are often empty) and names the two marketplaces, but it does not explain the limit parameter at all, leaving its meaning and effect ambiguous.

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

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

The description clearly states it searches products on Ozon or Wildberries via an embedded browser and returns a list of cards with links. It explicitly distinguishes what the tool does not provide (price, rating, reviews, availability) and differentiates it from parsee_parse_urls.

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 explicit usage guidance: use it to find products, not to study them; after receiving links, run parsee_parse_urls for detailed data. It also provides operational constraints: call one query at a time and prefer specific queries over general ones.

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 disclosure burden, and it does disclose the core behavior: the tool returns a short product overview and the two connection methods. The 'about' framing makes it clear this is an informational, non-mutating tool, though it does not explicitly state read-only behavior or any output details. Given the trivial, no-parameter nature of the tool, this is sufficient.

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 entire description is a single, colon-structured sentence that packs the product purpose, audience, content scope, and connection-method detail into very few words. 'коротко' sets length expectations, and every remaining part adds distinct information. There is no meaningful filler or buried context.

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

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

For a zero-parameter informational tool with an output schema, the description covers the essential content an agent needs to know. It could be slightly more explicit about when to choose this over parsee_cloud_manual or parsee_cloud_setup, but that gap is already reflected in usage_guidelines and the tool is simple enough that 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 is empty, so there are no parameters for the description to explain. The zero-parameter baseline is 4, and the description adds no unnecessary parameter information.

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 an informational purpose: it explains what PARSI is, who needs it, and briefly covers the product plus the two connection methods. This is distinct from action/resource siblings like parsee_cloud_setup or parsee_cloud_manual, but it never names those alternatives. It is clear but falls just short of explicit sibling differentiation.

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

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

The intended use is implied rather than stated: an agent would pick this tool when a user asks about PARSI generally or about connection options. There is no explicit 'use when/when not' guidance or reference to alternatives such as parsee_cloud_manual or parsee_cloud_setup. This is adequate but leaves selection to inference.

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

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

There are no annotations, so the description carries the full burden. It conveys that the tool is informational and tied to connection-time delivery, which implies no side effects, but it does not explicitly state read-only behavior, permissions, or output expectations.

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

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

The description is a single sentence that front-loads the key fact ('Полная инструкция') and adds one relevant contextual detail. There is no filler or redundant wording.

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 role and trigger. It would be more complete with a sentence relating it to parsee_help or clarifying when an agent should call it, but the low complexity keeps this a minor 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 input schema is empty with zero parameters, so there is no parameter documentation burden. The baseline of 4 applies because the description does not need to add parameter-level 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 identifies the tool as the full instruction text the server provides to the assistant on connection with a key, so an agent can understand its core purpose. It does not explicitly distinguish it from sibling tools such as parsee_help, 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?

The phrase 'при подключении с ключом' gives a specific context in which this manual is relevant, but there is no explicit guidance on when the agent should invoke this tool versus alternatives like parsee_help, nor any when-not-to-use statements.

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 must carry the behavioral disclosure burden. 'How to connect' suggests an instructional/read-only response rather than a state-changing operation, and the local/remote scope is stated. However, it does not disclose prerequisites, whether any configuration changes occur, or what the tool actually returns beyond being a guide.

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: core purpose first, then a terse client-value list. Every sentence earns its place, and there is no repetition of schema details or filler.

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

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

An output schema exists, so return-shape details are not strictly required in the description. The description covers the purpose and the client parameter well, but it lacks usage boundaries, behavioral caveats, and guidance relative to sibling tools. For a simple one-parameter tool this is close to complete, but the missing safety/behavioral context lowers it.

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 description for the 'client' parameter, so the description compensates by enumerating valid values: claude-code, claude-desktop, kimi, cursor, or any. This gives an agent concrete selection guidance. It still does not explain how each client affects the output, but the list is sufficient for basic invocation.

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 goal ('connect PARSEE to the assistant') and distinguishes local vs remote setup scenarios while listing supported clients. It does not explicitly differentiate itself from siblings like parsee_cloud_manual, but 'setup/connect' is specific enough to stand apart.

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

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

There is no explicit guidance on when to use this tool versus alternatives. Sibling tools such as parsee_cloud_manual and parsee_help could easily be confused with this one, and the description provides no exclusion criteria or 'use instead' hints.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It communicates that the tool returns a list and that the 'section' parameter filters that list. It does not explicitly state that the operation is read-only or side-effect-free, though the word 'list' strongly implies a non-destructive catalog operation.

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

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

The description is one short sentence plus a compact list of allowed values. Every part earns its place, and the core purpose is front-loaded. There is no redundancy or unnecessary detail.

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

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

This is a simple tool with one optional parameter and an output schema already present. The description covers the tool's purpose and the semantic meaning of the parameter. Nothing critical is missing for an agent to decide when to call it and what to pass.

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 only defines a string with a default of 'all' and no enum or description. The tool description adds meaningful value by enumerating the accepted section values: search, groups, analytics, settings, or all. It does not explain what each section contains, but for a straightforward catalog filter this is largely sufficient.

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

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

The description clearly states that this tool lists all PARSI tools, with an optional section filter. This distinguishes it from the sibling tools, which are individual operations rather than a catalog/discovery tool. The implicit verb 'list' combined with the resource 'all PARSI tools' is specific and unambiguous.

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

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

The description tells the agent the section values ('search, groups, analytics, settings, or all'), which implies usage for browsing available tools by category. However, it does not explicitly state when to prefer this tool over directly invoking a specific sibling tool, nor does it mention any exclusions or alternatives. Usage guidance is present but 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It provides a useful precondition ('group must have been assembled at least once') and summarizes what data is compared, but it does not mention side effects, error behavior, permissions, or whether the operation is read-only. This is partial transparency, not a contradiction.

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 focused sentence with no filler. It front-loads the core purpose (comparison within a group) and the output fields, then adds the required precondition. Every part 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?

Given that an output schema exists and there are only two parameters, the description covers the core purpose and a key precondition. The main gap is the unexplained 'limit' parameter and the lack of explicit routing relative to sibling tools. An agent could likely invoke the tool correctly for 'group', but might not know how to use 'limit'.

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 explains 'group' by describing it as a comparison group that must have been assembled, but it provides no meaning for the 'limit' parameter at all. Since one of the two parameters is effectively undocumented in both schema and description, the compensation is incomplete.

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 (comparison group) and the output content (price, rating, reviews, price difference, who is cheaper), and it distinguishes this tool from siblings like parsee_get_prices or parsee_price_history by framing it as 'my card vs competitor'. However, it lacks an explicit action verb such as 'compare' or 'returns', relying on the tool name and implied comparison to carry the action.

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 states a clear prerequisite: 'the group must have been assembled at least once', which gives some guidance on when the tool is usable. It does not explicitly mention when to use this tool instead of a sibling or when not to use it, so usage 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?

With no annotations, the description carries the burden and does disclose useful behavior: immediate population, section semantics, and the fromCabinet data-source fallback. It does not cover side effects, permissions, validation/error behavior, or how the group is represented in the system, which are significant 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 compact and front-loaded with the main action, then enumerates the section-specific payloads without filler. The dense one-paragraph layout could be slightly clearer as a short list, but 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 six-parameter creation tool with no annotations, the description covers the core workflows and the required section parameter thoroughly, and an output schema is present for return values. The main remaining gap is the unexplained vendorFilter parameter and the lack of explicit alternative routing to 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 description coverage is 0%, and the description compensates for most parameters: section values, items for monitor, pairs for compare, items+url/sent and fromCabinet for spp. However, vendorFilter and name are not given any descriptive 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 states a specific verb and resource — 'Создаёт группу и сразу наполняет её' — and then distinguishes the three supported section modes, making the tool's scope clear versus sibling group-management tools.

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 clearly tells the agent when to use this tool (creating a new populated group) and gives per-section payload advice for monitor, compare, and spp. It does not explicitly name sibling alternatives such as parsee_add_to_group, so it stops short of full when-not guidance.

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

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

With no annotations, the description carries the burden and explicitly discloses the irreversible destruction of the group and its check history, plus the requirement to pass confirm: true. It does not address errors or permission requirements, but the core destructive behavior is transparent.

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, each earning its place: the first states the function and scope, the second gives the essential safety instruction. 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?

The description is largely complete for a destructive tool: it states what is deleted, warns about irreversibility, and instructs the confirmation flow. An output schema exists, so return values need not be described. The only notable gap is the unmentioned 'section' parameter.

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 clarifies that 'group' is the deletion target and that 'confirm: true' is required to execute, but it says nothing about the optional 'section' parameter, leaving its role 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 starts with a specific verb and resource: 'Удаляет группу вместе с историей проверок' (deletes a group along with its check history). This clearly distinguishes the tool from siblings like parsee_remove_from_group (removal from a group) and parsee_rename_group.

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 provides a clear usage protocol: because deletion is irreversible, the agent must first ask the user and then call with confirm: true. It does not explicitly contrast this tool with alternatives or state when not to use it, but the context is unambiguous.

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

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

With no annotations provided, the description carries the full burden, and it does well by disclosing the save location, supported formats, and Excel-specific formatting. It does not mention overwrite behavior or file naming, but overall it gives substantial behavioral context for a non-destructive export 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?

Three short sentences each contribute unique information: action and destination, format list with semantics, and execution context with fallback instruction. The description is front-loaded and contains 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 one optional parameter and an output schema, the description covers the operation effect, parameter meanings, and prerequisite workflow. Missing details like overwrite behavior and what happens when format is null are minor given the simplicity of the tool and the presence of structured schemas.

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

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

Schema description coverage is 0%, but the description compensates by explaining each format value in plain language: excel as a table, zip as an archive with photos and files, and csv/json by name. It also adds useful detail about Excel numeric formatting. The only minor gap is the meaning of the default null, but the enum values themselves are well documented.

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 uses a specific verb, saves collected cards to Downloads, and enumerates the supported formats. It clearly distinguishes itself from sibling tools like parsee_get_results and parsee_parse_urls by focusing on the export-to-file action and the last collection.

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 that the tool operates on the last collection and instructs to call parsee_parse_urls first if no cards exist. This provides a concrete when-to-use condition and names the relevant alternative, which is exactly the guidance an agent needs.

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 burden. It states that the tool returns current values and allowed modes, making its read-only, query-like nature clear. It does not discuss side effects, but for a no-parameter getter this is a minor omission.

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

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

The description is a single, front-loaded sentence that lists the option areas and then states the return behavior. The list is long but purposeful, since it tells an agent exactly what this options getter covers.

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-argument getter with an output schema and no annotations, the description is largely complete: it identifies the subject and the return semantics. It could strengthen the definition by explicitly noting that no settings are changed and by referencing set_options, but these are not critical 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 has no parameters and the input schema is empty, so the baseline is 4. The description adds useful context about what the referenced options cover, even though there is nothing to document about argument semantics.

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

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

The description clearly states that the tool returns current values and the list of allowed modes for the data-collection options, and it enumerates the specific option categories. This distinguishes it from related getters like get_prices or get_results, though it does not explicitly name a sibling such as set_options.

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 used to inspect current parsing/collection options and valid modes. However, it does not explicitly say when to use it instead of related tools or mention set_options as the counterpart for changing these values.

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 behavioral disclosure. It already explains that results come from the last check, that no new data collection happens, and that both showcase and card/wallet prices are included. It does not cover permissions, rate limits, or failure behavior, but for a simple getter this is reasonable.

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 three short sentences with no filler. It front-loads the core purpose, then adds useful details about price variants and data freshness/performance. 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?

This is a simple two-parameter getter and the presence of an output schema covers return-value structure. However, with no annotations and zero schema parameter descriptions, the meaning of 'limit' and how exactly to specify 'group' remain underspecified, so an agent would need to guess or rely on sibling tool names.

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

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

Schema description coverage is 0%, and the description only implies that 'group' identifies the product group. The optional 'limit' parameter is not explained at all, and no format or identifier details for 'group' are provided. The description does not compensate for the schema's lack of parameter documentation.

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 retrieves current prices, availability, and ratings for a group's products, based on the last check. It has a specific resource and an implied read verb, but it does not explicitly distinguish itself from sibling tools like parsee_price_history or parsee_get_results.

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 says the data are already collected and the response is instant, making it clear this is a cached/fast path rather than a fresh collection operation. However, it does not explicitly mention when to prefer alternatives such as parsee_run_check, leaving some inference to the agent.

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. It discloses that the tool returns the current city and available list, and the verb 'возвращает' plus the getter-style name clearly imply a read-only operation. It does not discuss auth or rate limits, but those are not critical for a zero-parameter getter.

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: it states the core purpose, gives a brief reason why this matters, and specifies the return value. Every sentence earns its place with no redundant or vague 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?

This is a simple zero-parameter getter, and the description fully covers what it does and what it returns. The output schema is already available, so no additional return-value detail is required.

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

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

The tool has zero parameters, so the baseline of 4 applies; there is no parameter ambiguity for the description to clarify. The empty schema and the description are consistent.

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

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

The description clearly states the tool's purpose: it reports which city PARSI uses for price lookups, and it explicitly returns the current city and the list of available cities. This distinguishes it from sibling tools like parsee_set_region and parsee_get_prices.

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

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

The description provides relevant context by explaining that prices and availability vary by city, which implies when an agent should call this tool before interpreting prices. It does not explicitly list exclusions or compare against alternative tools, but the intended usage is 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 provided, the description carries the burden of behavioral disclosure. It reveals the default limit of 50 cards, pagination via offset, search behavior, and the difference between partial and full cards. It does not explicitly discuss side effects, but the read-only nature is clear from context.

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, front-loads the core purpose and key fields, and then packs usage guidance into two sentences. Every sentence earns its place with no repetition or filler.

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

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

The description covers what the tool returns, how it relates to the parse workflow, default pagination, search, and the full-card option. Even though no output schema was shown, the description itself provides enough context to invoke the tool correctly and understand its results.

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

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

Schema description coverage is 0%, so the description compensates by explaining full, offset, and search, and by implying limit through the default of 50 cards. It does not name limit explicitly, but the meaning is sufficiently inferable.

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

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

The description states a specific verb ('отдаёт') and resource ('данные последнего сбора'), enumerates the returned fields, and explicitly differentiates this tool from search output. It is easy to distinguish from sibling tools such as parsee_get_prices or parsee_browser_search.

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

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

It clearly explains that this tool returns the result of parsee_parse_urls and should be used for conclusions, not the search output. It also gives practical guidance on pagination, search, and the full flag, making it explicit when and how to use it.

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 adequately explains what the tool returns — schedule information for automatic group launches — and notes the default behavior when no parameter is passed. However, it does not explicitly state read-only behavior, error cases, or what happens if the group does not exist.

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

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

The description is two short sentences with no filler. It front-loads the core behavior and then adds the important default-mode detail. Every clause 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 read tool with one optional parameter and an output schema available, the description is nearly complete. It states the purpose, trigger types, and default behavior. The only notable gap is the lack of an explicit statement about the parameter's filter semantics, but this is reasonably inferable from the schema and the default note.

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 itself provides zero description coverage for the 'group' parameter, so the description must compensate. It does so by noting that omitting the parameter returns all schedules, which implies the parameter serves as a group filter. This adds meaning beyond the bare schema, though it stops short of explicitly stating that passing a group name filters to that group's schedule.

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 clear action ('Показывает, когда группы запускаются сами') and a specific resource (group schedules), and it distinguishes the tool from the sibling parsee_set_schedule by being the read/get counterpart. It also clarifies the scope: all schedules by default, with specific trigger types (weekday time or every N hours).

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

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

The description provides useful context for calling the tool: without the parameter, all schedules are returned. However, it does not explicitly state when to prefer this tool over alternatives, nor does it give any when-not-to-use guidance or name sibling tools like parsee_set_schedule or parsee_status.

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

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

With no annotations, the description carries the full burden, and it does disclose that the tool returns complete instructions identical to what the local server provides on connection. This clearly signals an informational, non-mutating help tool, and no hidden side effects are suggested. The exact output structure is not described, but an output schema exists.

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

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

The description is a single sentence with the core purpose front-loaded: 'Полная инструкция по ПАРСИ'. The clarifying clause about the local server is relevant context and adds no unnecessary bulk.

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 has no parameters, an output schema exists, and a help tool should simply return the manual, the description provides sufficient context. An agent can correctly identify the tool's purpose and invoke it without ambiguity.

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 properties, so there are no parameters to document; the baseline of 4 applies. The description adds no parameter-related claims, which is appropriate for a no-argument help 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 clearly identifies the tool as providing the complete PARSI instructions, and the phrase 'та же, что отдаёт локальный сервер при подключении' adds useful context about the source of the manual. However, it doesn't explicitly differentiate it from the sibling parsee_cloud_manual, which sounds similar in purpose.

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 should be used to obtain the full PARSI manual, especially the same one shown on local server connection. It gives no explicit when-to-use guidance or alternatives, so the agent must infer usage from the tool name and description.

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

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

With no annotations, the description carries the burden, and it does disclose that the tool returns a set of group fields, implying a read operation. However, it does not explicitly state that it is non-mutating, nor describe what happens with the 'section' filter or edge cases. The output schema covers return structure, so this partial transparency is adequate but not rich.

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

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

Three short sentences convey purpose, return fields, and workflow placement with no filler. The most important guidance (start here) is at the end but the content is compact and every clause 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 list tool with one optional parameter and an output schema, the description covers the domain, return data, and usage context. It does not explicitly explain how the optional 'section' filter behaves, but the enum values plus domain hints make the definition workable; a slightly clearer parameter mapping would make it 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%, so the description must add meaning to the 'section' parameter. It maps the enum values to domain categories ('мониторинг цен', 'сравнение с конкурентами', 'СПП'), which is useful, but it never explicitly ties this to the parameter or explains the default/null behavior. This is partial compensation for the missing schema descriptions.

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

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

The description identifies a specific resource—user groups in PARSI—and states what the tool returns: group name, section, product count, and last check time. It is distinguishable from the sibling group tools mainly through the phrase about starting here and other tools operating by group name, though it relies on the verb 'Возвращает' rather than an explicit verb like '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 sentence 'С этого стоит начинать' gives explicit guidance to use this tool first, and 'дальше по названию группы работают остальные инструменты' clarifies the workflow context. It doesn't list formal exclusions or alternatives, but for a read/list entry point that is sufficient.

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 disclosure burden. It conveys that this is a comparison/report over previously captured check data, not a mutation or a new check trigger, and it exposes the no-group fallback behavior. It leaves limit semantics and the no-previous-check edge case undisclosed, but the core behavioral profile is clear.

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 wastes no words, front-loading the purpose and then listing result categories. It is slightly telegraphic ('Что изменилось...', 'Без группы — по последней проверке'), but it earns its 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 two-optional-parameter report tool, the description covers the main purpose, output categories, and the group default, and an output schema exists to describe return values. The limit parameter is entirely unexplained and the no-previous-check case is not addressed, so the definition is minimally viable but has a clear 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 coverage is 0%, so the description is the only source of parameter meaning. The final clause gives some meaning to group (optional; fallback to the last check), but nothing is said about limit, an integer parameter that likely caps how many results are returned. The compensation for missing schema descriptions is therefore incomplete.

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 defines a concrete outcome: report what changed for tracked products since the previous check, and it lists the exact change categories (price with old/new/percent, availability, sales scheme, rating, new items). This makes it clearly distinguishable from sibling price/status tools in spirit, though it never names a specific sibling.

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

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

The description implies when to use the tool: when the agent needs a delta report since the last check, and it explains the behavior when group is omitted. It does not, however, tell the agent when to prefer this over parsee_get_prices, parsee_price_history, or parsee_spp_changes, nor does it state 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 disclosure burden. It is transparent about the main side effect — the tool 'запускает сбор' (launches collection) — and documents the onlyLinks=true escape hatch that returns links without collecting. However, it does not explain what launching collection entails downstream (e.g., scheduled runs, group membership, how to stop it), even though siblings like parsee_stop and parsee_status hint at async 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?

Two compact sentences deliver the core action, the use case, and the key option with no filler. The onlyLinks hint is appended after the prose rather than structured, but it earns its place because it documents the most important behavioral switch.

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 3-parameter tool with an output schema, the description covers the main purpose and the onlyLinks behavior adequately. Gaps remain: 'limit' semantics are absent, and the collection-launching behavior is not connected to the tool ecosystem (how to monitor or stop it), which matters given related siblings parsee_wait, parsee_status, and parsee_stop.

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?

At 0% schema description coverage, the description must compensate for bare schema properties. It adds meaning to url (accepted link types: category, search, brand, seller) and to onlyLinks (return links only, without collection), but leaves 'limit' completely unexplained — an agent cannot determine whether it caps cards, pages, or something else.

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 ('разворачивает' — expands) with a clear resource (links to categories, search results, brands, sellers) and outcomes (a list of cards and launched collection). It also distinguishes itself from the page-by-page scraping approach and from sibling parsee_parse_urls by framing this as whole-market capture.

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 clear guidance on when to use the tool: when the goal is to capture the entire market rather than iterate search pages one at a time. It implies the alternative approach but does not explicitly name a sibling tool as the counter-option.

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 proactively discloses asynchronous behavior, execution location, latency characteristics, and the immediate return value, plus where to retrieve results. It could mention failure modes or prerequisites, but it already provides substantial behavioral context beyond a bare 'launches collection' statement.

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

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

Two sentences with no filler: the first names the action and scope, the second explains execution behavior, return signal, and follow-up tools. It is front-loaded and every clause 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 one-parameter async launch tool, the description covers input, process, runtime expectations, immediate return, and result retrieval. The output schema exists, so return-value details do not need to be repeated. It could additionally mention list-size limits or setup requirements, but the description is largely complete 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 schema only says 'urls' is an array with empty item definitions (0% coverage). The description compensates by explaining the parameter is a list of links or articuls and implies the content type. It doesn't specify exact item format or constraints, but for a single simple parameter it adds enough 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 action ('Запускает сбор карточек' — launches card collection), the input ('по списку ссылок или артикулов'), and the data collected (name, prices, rating, reviews, photos). It does not explicitly contrast itself with sibling parsing tools such as parsee_parse_category, but the list-of-links/article framing makes the scope reasonably 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?

Usage context is implied rather than explicitly stated: use this when you have a list of links or articuls and want to launch collection. The description gives important expectations (runs on the user's computer, has pauses, takes time, returns 'task launched') and points to follow-up tools, but it names no alternative tools or conditions for choosing this over 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?

With no annotations provided, the description carries the disclosure burden. It does disclose a meaningful behavioral constraint: results come from saved checks, not live or fresh data. However, it does not clarify side effects, read-only enforcement, error cases, or how the optional period parameter affects 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 two short, focused clauses with no filler. Every sentence adds useful information: one defines the purpose and data source, the other defines the item input format.

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 is adequate for a basic invocation: the required item parameter is explained and the overall behavior is clear. It is not fully complete because the days parameter is undocumented, and there are no annotations to clarify safety or data-source limitations, though the presence of an output schema reduces the need to describe return values.

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

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

The input schema provides no descriptions, and the description adds meaning for the required item parameter by stating it can be a link or article. However, it says nothing about the optional days parameter, its default, or how it controls the reported period, leaving a notable semantic gap.

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

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

The description clearly states that the tool reports how a product's price changed over a period based on saved checks, and it specifies that the product is identified by link or article. This is enough to distinguish it from siblings like parsee_get_prices or parsee_monitor_changes, though it does not explicitly name any alternative.

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 retrieving historical price trends of a specific item from previously saved checks. It does not explicitly state when to prefer this tool over alternatives such as parsee_get_prices, nor does it describe exclusions or prerequisites beyond the implied reliance on saved checks.

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 does disclose a useful behavioral detail: removal does not delete the group itself. However, it does not mention whether removal is reversible, whether permissions are required, how missing items are handled, or any side effects beyond removing the positions.

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

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

The description is a single sentence with no filler. It front-loads the core action, states the identification method, and adds the important nuance that the group remains. Every part contributes value.

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

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

For a 3-parameter tool with no annotations, no output schema, and no per-parameter descriptions, this description is too thin. The optional 'section' parameter is never mentioned, so an agent cannot know when or how to provide it. The description is adequate for a high-level summary but not fully complete for reliable invocation.

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

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

The schema has 0% description coverage, but the description gives meaning to two key parameters: 'items' are positions identified by link or article, and 'group' is the target group. The optional 'section' parameter is not explained, and the accepted formats for group or items are left 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 uses a specific verb ('Убирает' / removes) and a clear resource ('позиции из группы' / items from a group), and it explains the identifying criteria (link or article). It also clarifies the group itself remains, which helps distinguish it from deletion-style operations. It does not explicitly contrast with sibling tools, but the operation 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 about when to use this tool versus alternatives such as parsee_rename_group or parsee_parse_category. No prerequisites, exclusions, or typical scenarios are provided. The only implied usage is 'when you need to remove items from a group.'

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 disclosure burden. It usefully discloses that check history is preserved, and the mutating nature is clear from 'меняет'. However, it does not mention permissions, reversibility, or side effects on references to the old group name.

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 no filler. The action is front-loaded, and the second sentence adds meaningful behavioral information about history preservation.

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 mutation tool with no annotations and no schema descriptions, this is too thin. It leaves unclear how to identify the group, what section controls, and whether any prerequisites or side effects apply. An output schema may exist, but important input semantics are still missing.

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

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

Schema description coverage is 0%, and the description only indirectly clarifies group and newName. It adds no explanation for the optional section parameter, the expected format of group, or constraints on newName. The schema's enum and property names provide partial meaning, but the description does not compensate for the missing parameter documentation.

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

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

The description clearly states the action with a specific verb and resource: 'Меняет название группы' (changes the group name). It is distinct from sibling tools like create/delete/add/remove, though it does not explicitly name alternatives.

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

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

No guidance is provided about when to use this tool versus related group-management tools, whether the group must already exist, or how the optional section parameter affects the operation. Usage context must be inferred entirely from the tool name and schema.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose an important trait: the operation is asynchronous and only returns a task-launched confirmation. However, it does not mention side effects, prerequisites, error behavior, or whether launching a check replaces or duplicates an existing run.

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 the primary purpose stated first and the async behavior second. There is no fluff or repetition of schema fields, and every sentence adds useful information.

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

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

The description covers the core behavior and immediate return value, and an output schema exists for the response. Still, it omits follow-up steps such as checking status or retrieving results via related tools, and it leaves the group parameter's format underspecified. For a simple launch operation this is adequate but not 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%, so the description must explain parameters. It adds meaning by mapping the kind enum: 'monitor' corresponds to price monitoring and 'spp' to СPP. It also clarifies that 'group' is the group being checked, but it does not specify whether group is an ID, name, or other identifier.

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: it launches a group check, scoped to price monitoring or SPP. This clearly conveys what the tool does, though it does not explicitly distinguish itself from closely related sibling tools like parsee_monitor_changes or parsee_spp_changes.

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 purpose implies when to use it: when you need to start a check on a group. The statement that it takes time and returns 'task launched' gives some expectation-setting, but there is no explicit guidance about alternatives or when not to use this tool, such as using parsee_get_results or parsee_wait for outcomes.

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 factual burden. It discloses that unmentionned settings are preserved, that this is a mutation of pre-collection settings, explains the three speed modes with risk tradeoffs, and notes the performance impact of disabling photos/reviews. It does not discuss persistence or permissions, but core side effects are covered.

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

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

Three focused sentences: purpose, partial-update semantics with an example, and mode/performance guidance. No filler, with the most important information 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?

The tool has 17 optional parameters and no annotation coverage; the description explains overall semantics and a few settings, but not the complete set. An output schema exists, so return values need not be described, and the example helps, but the description is not fully complete for invoking every parameter with confidence.

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 defines the 'mode' enum values and gives an example with 'images', 'reviews', and 'reviewsLimit'. However, the other parameters are left to inference from their names, with no explicit semantics. This is only partial compensation.

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

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

The description opens with 'Меняет настройки перед сбором' — a specific verb ('changes'), a clear resource ('settings'), and a temporal scope ('before collection'). It also states the partial-update behavior, which separates it from the read-only sibling parsee_get_options.

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 clear context: call this to adjust collection settings in advance, and pass only the fields you want changed. It provides a concrete JSON example and speed-mode guidance. It does not explicitly name alternatives or exclusion cases, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and delivers: it warns that already collected data is not recalculated, advises rerunning the check, and clarifies that underlying WB/Ozon differences are irrelevant. This is strong side-effect disclosure for a setter.

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

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

Three sentences, each earning its place: action, platform nuance, and side-effect warning. No filler and the main purpose 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 one-parameter setter with an output schema, the description covers the essential behavior, parameter semantics, and post-condition. It could mention how to read the current region, but that is a routing nicety rather than a correctness 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 coverage is 0%, but the description compensates: 'достаточно назвать город' tells the agent the parameter is simply a city name and platform-specific codes are not required. This adds real meaning beyond the bare string type.

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

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

The description opens with 'Меняет город, из которого смотрятся цены на Wildberries и Ozon' — a specific verb, resource, and purpose. It clearly distinguishes this setter from the sibling getter parsee_get_region.

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 this tool to change the city used for price lookups, and rerun the check after changing. It does not explicitly mention alternatives like parsee_get_region, but the usage scenario is unambiguous.

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

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

With no annotations, the description carries the disclosure burden. It specifies Moscow time, the ability for the from/to window to span midnight, and that the section is inferred from the group name. It does not mention whether an existing schedule is overwritten or what happens for unsupported groups, but the behavioral details go well 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 packs mode selection, examples, timezone, disable behavior, and scope into a few compact sentences with no filler. The examples are concrete and the structure follows the order an agent would need to compose a call.

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 eight parameters, no annotations, and no schema descriptions, the description covers the core behavior and parameter semantics well enough to construct a valid call. Minor omissions include the effect of re-setting a schedule and handling of invalid or unsupported groups, but the required group parameter's role is implied and an output schema exists.

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?

At 0% schema description coverage, the description explains almost every parameter: mode values, days 1..7 with 1=Monday, times examples, everyHours, from/to window, and enabled=false. It does not literally name the 'group' parameter or the underscore in 'from_', but the examples and phrasing make the mapping clear.

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

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

The description opens with a clear verb and object ('Ставит автоматический запуск группы') and then explains the two scheduling modes. This makes it unmistakable that the tool sets an automatic schedule for a group, distinguishing it from siblings like parsee_get_schedule, which reads schedules.

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 explicit instructions for choosing between mode='week' and mode='every', provides a disable path via enabled=false, and states which group types are supported. It does not explicitly name alternatives such as parsee_get_schedule for reading or parsee_stop for stopping, but the usage context is still 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 behavioral burden and does add useful context by defining the SPP formula and the output framing (was, became, difference in pp). However, it does not disclose whether the tool is read-only, how the optional group parameter affects behavior, or any limitations.

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

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

Three compact sentences, each earning its place: the core answer, the formula, and the trigger phrases. The most important context is front-loaded with 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?

The formula and usage triggers are helpful, and an output schema is present, but the single optional parameter is completely undocumented. Without annotations, the description also leaves assumptions about side effects and read-only behavior unstated, so correct invocation is not fully supported.

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, `group`. The agent has no information about what group means, how it filters results, or what values are acceptable, so the description adds nothing to parameter understanding.

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

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

The description states exactly what the tool reports — where the regular-customer discount shifted, with was/became/difference in percentage points — and defines SPP via formula. It is specific enough to distinguish it from siblings like parsee_price_history or parsee_compare_diff.

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?

Explicit usage triggers are provided: use when the user asks 'where the discount dropped' or 'what changed in SPP'. It gives clear context for when to call the tool, though it does not name alternative tools or state when not to use it.

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 full burden for behavioral disclosure. It discloses what status information will be surfaced and implies that calling it does not start collection, but it does not explicitly state that it is read-only or describe any side effects or 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 tight sentences: the first enumerates the status fields, the second gives a practical reason to call the tool. Every clause adds value, and the most important usage guidance is placed at the end without 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 parameterless status tool with an output schema present, the description is complete. It tells the agent what to expect, why it matters before long actions, and what to watch for (an already-running collection). Nothing essential is missing.

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

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

The tool has zero parameters and the input schema is an empty object, so there is nothing for the description to explain. The baseline for a parameterless tool is 4, and the description appropriately focuses on the returned status content rather than inputs.

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

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

The description clearly explains what the tool reports: app version, account/tariff, Ozon/Wildberries login state, collection progress, and collected card count. It is distinct from sibling tools because it is a status snapshot rather than a configuration, execution, or export action, though it does not explicitly name a competing sibling.

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 explicit usage context: call before long-running actions to avoid starting a second collection if one is already in progress. This is a clear when-to-use and when-not-to-use signal, but it does not identify an alternative tool by name.

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

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

With no annotations, the description carries the full burden, and it discharges it well: it explicitly states that already-collected cards are preserved and can be exported, and that an idle call produces an honest report. It does not detail cancellation timing or effect on scheduled tasks, but the core non-destructive behavior is disclosed.

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, front-loaded sentences. The first states the primary action, and the second adds important safety and behavior guarantees. There is no filler or redundancy.

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

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

For a 0-parameter tool with an output schema, the description covers all essential context: what is stopped, what is preserved, and what happens when nothing is running. No additional operational details are necessary for correct invocation.

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

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

The input schema has zero parameters and 100% schema coverage, so the description is not required to add parameter semantics. The baseline score for 0-parameter tools is 4, and the description adds no contradictory or misleading parameter information.

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 action ('stops the running collection') and the resource ('collection'), leaving no doubt about the tool's purpose. It does not explicitly distinguish itself from siblings like parsee_status or parsee_wait, but confusion is unlikely because it is the only stop/abort tool.

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 while a collection is running, and it can safely be called even when nothing is running since it will report that honestly. It does not mention alternatives or exclusions, but none are really needed for a unique 0-parameter stop action.

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 disclosure burden. It reveals key behaviors: it blocks until completion, has a 300-second default wait, and reports partial progress if the timeout is reached. It does not mention error behavior or cancellation, but for a wait tool this is solid coverage.

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

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

Three sentences, front-loaded with the core behavior, followed by usage context and timeout behavior. No redundant content; 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 single-optional-parameter tool, the description covers the main operational context: when to call it, default wait time, and behavior on timeout. It could note what happens if no job is running, but the existing detail is sufficient for most agent use.

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 mentions the 300-second default but never explicitly connects the timeoutSec parameter to that default or explains how to override it. The parameter name is somewhat self-explanatory, but the description adds minimal semantic value for the one parameter.

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

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

The description clearly states the tool's function: it waits until collection/check completes before responding. It names the exact preceding tools (parsee_parse_urls, parsee_parse_category, parsee_run_check) to invoke it after, distinguishing it from a blind status-polling approach.

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?

Provides explicit when-to-use guidance: call immediately after the three parsing/check tools. It implies the alternative is manually polling status, though it doesn't name parsee_status as the alternative tool, which would make the guidance fully explicit.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose meaningful traits: the source of data, the difference between checking connection and syncing, and that the access key is entered by the owner and invisible to the assistant. However, it omits potential side effects, permissions/authentication constraints beyond key visibility, and behaviors around search or limit.

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

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

The description is compact and efficient: it states the purpose first, then explains the two action modes, and finishes with an important security note. Every sentence earns its place and there is no redundant 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?

The output schema exists, so return-value details are not needed, and the description covers the main action parameter. But with two undocumented parameters and no guidance relative to closely related sibling tools, the overall picture is only partially complete for an agent deciding how 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?

Schema description coverage is 0%, so the description must compensate. It explains the 'action' parameter well, giving real semantics to the 'status' and 'sync' enum values. But 'limit' and 'search' are completely undocumented; especially 'search' is ambiguous (searches what? in which field?). This is a significant gap for two of three 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 resource: prices the seller sent to Wildberries, used as the source for SPP calculations. It then gives specific action semantics — status checks whether the cabinet is connected, sync updates and shows prices with nmID, article, transmitted price, and WB Club price. It does not explicitly contrast itself with siblings like parsee_get_prices, parsee_price_history, or parsee_spp_changes, 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?

The description gives clear context on when to use each action: use 'status' to check if the cabinet is connected, and 'sync' to update and display prices. However, it does not mention when to prefer this tool over the related price/SPP siblings, nor any exclusions.

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