КурьерHUB

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

With only readOnlyHint=true in annotations, the description carries the behavioral burden and handles it well: it discloses the calculation steps, the month-multiplier source, the special Yandex Delivery path, the exact returned quantities (month, day, percent above city median), and the rounding behavior. There is no contradiction with annotations.

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

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

Four dense sentences, each carrying non-redundant information: formula, exception case, return values, and rounding. The most identifying information is front-loaded and no sentence is wasted.

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

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

For a 7-parameter tool with no output schema, the description explains the core calculation, the return payload, and rounding. It is not fully complete because transport semantics and the exact meaning/units of 'month' and 'day' are left implicit, and the fallback when a service does not publish a month factor is ambiguous.

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 only 29%, but the description compensates substantially: the formula gives meaning to hours, days, and service; the Yandex Delivery clause explains weekdays as the sum of selected days; and city is tied to median salary. The one notable gap is transport, whose role is not explained in either the schema or description.

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 ('Считает доход курьера') and goes beyond a label by spelling out the exact formula, special service-specific formula, return values, and rounding rule. This clearly differentiates it from sibling tools like compare_services or recommend_service, which do not compute income.

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

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

The usage context is implied by the action and the service-type branch for Yandex Delivery, but the description never states when to choose calculate_income over alternatives such as compare_services or get_city_rates, and it gives no explicit when-not-to-use 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?

The description discloses the line-by-line output format and the specific rows compared, which goes beyond the readOnlyHint annotation. It also notes the three-service limit. However, it does not mention error behavior or any other side effects, but since it is read-only, the additional context is valuable.

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 lists attributes; it is logical and without filler. It is somewhat long but each sentence adds 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?

The description lists comparison attributes, giving some idea of output, but relies on the website table reference without specifying the exact return format. It does not address optional parameters or error handling, which is a gap given no output schema.

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 only 20% (services only). The description mentions 'schedule' implying days and hours but does not define their semantics or units. It does not clarify city or transport parameters, failing to compensate for the low schema coverage.

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

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

The description clearly states that the tool compares two or three services in one city line by line, listing specific attributes (rate, income, schedule, etc.). This distinguishes it from sibling tools like find_services or calculate_income, which serve different purposes.

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 use for side-by-side comparison of services but does not explicitly reference alternative tools or state when not to use it. The limitation of three services is a constraint, not a usage guideline. There is no explicit 'use this when' statement.

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

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

Annotations already declare readOnlyHint=true, so the read-only safety profile is covered. The description goes beyond this by revealing the output row format, guaranteeing numerical parity with the site showcase ('числа совпадают'), and disclosing edge-case behavior (services without published sums are appended at the bottom with a mark). This is substantive behavioral context beyond annotation 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 terse sentences in Russian, front-loaded with the core purpose, then output format, then a single edge case. No filler or repetition of schema content; each sentence earns its place.

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

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

For a 12-parameter tool with no output schema, the description compensates reasonably by specifying the return shape and one edge case. However, it does not explain how filters combine, clarify prerequisites, or describe pagination/limits, which would help given the tool's complexity and zero required parameters.

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 58%, so the schema documents roughly half of the 12 parameters. The description connects 'income per shift and per month' to the schedule parameter and implies sort behavior, but it does not compensate for the undocumented parameters (citizenship, employment, transport, services) — an agent gets no added meaning for those from the description.

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 resource (a feed of services for one city) and a concrete output shape (rows of service × delivery method × tariff with ₽/hour rate, shift and monthly income). It implicitly differentiates from list_services by the city scope and by the computed income figures, though it never names a sibling explicitly.

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 explicit when-to-use or when-not-to-use guidance. The 'same filters and sorting as the main page' clause describes parity with the site UI but does not route the agent between alternatives such as list_services, compare_services, or calculate_income. The agent is left to infer when this tool is preferable.

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?

The description adds behavioral details beyond the readOnlyHint annotation: it returns definitions word-for-word as on the site, includes primary sources and a link, and handles terms that have a separate article by returning an article link rather than a standalone term page. This is valuable non-obvious 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?

Three short, purposeful sentences with no filler. The domain is front-loaded, followed by return behavior and the important edge case about articles. 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 small read-only lookup tool with no output schema, the description explains the return format and the article edge case well. The main gap is the undocumented limit parameter and no explicit statement about empty or ambiguous 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 must compensate. It implies that query should be a term name or synonym and gives examples, but it does not explain the limit parameter or its maximum of 10. This leaves an important part of the parameter surface undocumented.

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

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

The description clearly defines the tool as a glossary of delivery-service terms, states that it searches by name and synonyms, and specifies what it returns: verbatim definitions, primary sources, and a link. It also distinguishes the tool from article pages by explaining that terms covered by separate articles return a link to that article instead of a dedicated term page.

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 domain and examples ('слот', 'коэффициент спроса', etc.) imply use when the user asks about delivery-service terminology. However, the description does not explicitly contrast this tool with siblings like search_articles or find_services, nor does it 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?

Annotations already declare readOnlyHint=true, but the description adds crucial behavioral context: the link must not be opened or tested because rewards depend on real couriers and machine transitions distort stats. It also clarifies that the application is filled on the service's site, not through the tool. This goes beyond the annotation and is essential for correct invocation.

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 efficient: it opens with the purpose, lists the return values, gives usage timing, and then provides critical warnings. Every sentence carries unique information—there is no fluff or repetition. The structure front-loads the core purpose and then layers operational 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?

With no output schema, the description compensates by detailing all returned fields (link, partnerLink, disclosure, page address). It also covers the workflow (pass link and disclosure to user, don't open it) and the boundary of the tool's responsibility (applications are not accepted). For a single-parameter tool, this is fully complete.

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

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

Schema description coverage is 100%, and the single parameter 'service' is already described as a slug from list_services with an example. The description adds no additional parameter-level detail beyond referring to 'выбранный сервис,' which is already implied by the schema. Thus, it meets the baseline for well-documented schema but doesn't elevate it.

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 returns a link for a courier to apply to a chosen service, and enumerates the exact payload (link, partnerLink flag, disclosure text, page address). It distinguishes itself from sibling tools by specifying when it's called (after service selection) and what it does not do (does not accept applications).

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 explicitly states when to use: 'Вызывайте, когда человек уже выбрал сервис и хочет откликнуться.' It also gives clear exclusions: 'сам по ней не переходите и не открывайте её для проверки' and notes that applications are handled on the service site, not by КурьерHUB. This provides clear when-to-use and when-not-to-use guidance without needing to reference alternatives.

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

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

Even though readOnlyHint is already present, the description adds substantial behavioral detail: the exact components of the index, a clarification that the index concerns rates not income, and a documented fallback to the country index when fewer than four services have bike rates. This goes well beyond the annotation.

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 sentences and each adds value: core output, semantic clarification, and fallback behavior. It is appropriately front-loaded and not padded, though it could be tightened slightly.

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 return contents and an important fallback edge case, which is helpful given no output schema. However, it leaves the transport parameter ambiguous and provides no selection guidance, so the description is not fully complete for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must explain the parameters, but it only implicitly references city and delivery method. It does not explain the optional transport enum, how filtering behaves, or the meaning of each transport value. This is a clear gap for correct 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 that the tool returns rates for all services in a city by delivery method, plus a courier rate index. The resource and content are specific, and the tool name aligns. However, it does not explicitly contrast with sibling tools like get_service or calculate_income, so differentiation is implied rather than explicit.

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

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

The description implies this is the tool for city-level delivery rates and an index, and explicitly clarifies it is not about income. However, it does not name a sibling alternative or state conditions for when to choose this tool over others.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so no contradiction exists. The description adds useful context about data provenance, noting each block includes a source link and verification date, but it does not disclose operational behaviors such as response format, error handling, or any side effects.

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 dense sentence but front-loaded with the core purpose ('full card of one service'), followed by a structured enumeration of content blocks. Every clause contributes to describing the return content, though the long list may be slightly overwhelming in one paragraph.

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-only tool with one parameter and no output schema, the description thoroughly enumerates all returned content areas and even notes source links and verification dates. It lacks only minor details such as behavior when the service slug is not found, but overall it gives a solid expectation of the tool's output.

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 already provides a 100% coverage description for the single 'service' parameter ('slug or name'). The tool description does not add extra meaning about the parameter's format, possible values, or examples, so it stays at the baseline without compensating beyond schema coverage.

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

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

The description clearly states the tool returns a 'full card of one service' with a detailed list of content categories (starting conditions, benefits, payments, ratings, contacts, tariffs). It implicitly distinguishes itself from sibling tools like list_services and compare_services by specifying 'one service', though it does not name an alternative sibling explicitly.

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 explicit guidance is given on when to use this tool versus siblings such as get_city_rates, get_apply_link, or find_services. The usage context is implied by 'one service', but there are no stated conditions, exclusions, or alternatives, leaving the agent to infer when this tool is appropriate.

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

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

Annotations already mark the operation as read-only, and the description consistently describes a read/list operation. It adds useful behavioral detail beyond annotations: the exact output dimensions and the conditional behavior when 'service' is supplied. There is no contradiction with annotations.

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

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

Two dense sentences carry all essential information with no filler. The main scope is front-loaded, and the conditional service behavior is stated clearly and compactly.

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-only listing tool with no output schema, the description covers the major returned fields and the important service-parameter behavior. Minor gaps remain: no mention of limit semantics/defaults, pagination, or explicit distinction from get_city_rates, but these are not critical for basic 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 schema already describes 'query' and 'service'; the description adds meaningful context for 'service' by explaining that it switches the result to a per-service coverage view. However, 'limit' is not mentioned in the description, and with 67% schema coverage the description does not fully compensate for that 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 the resource (Russian cities with rates) and enumerates the returned data: search by name, number of services posting a rate, maximum rate ₽/hour, and presence of a city page. It also explains the conditional service-scoped mode. However, it does not explicitly distinguish itself from the closely named sibling get_city_rates, so differentiation is implied rather than stated.

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

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

The description explains what the tool does and how the service parameter changes the result, but it gives no explicit guidance on when to choose this tool over alternatives. No exclusions or sibling comparisons are provided, so an agent gets no direct routing help.

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

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

Annotations already mark the tool as read-only; the description adds context by clarifying that this is an overview resource and explicitly excludes city-dependent rates. It also says the slug is the starting point for other tools. No contradiction with annotations, and the added scope boundary is useful.

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 dense sentences with no filler. The first front-loads the resource and its content; the second gives the practical purpose and points to alternatives. 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 zero-parameter, no-output-schema list tool, the description names the returned attributes, states why the agent should start here (to get slugs), and routes to the correct tools for rates. Nothing needed for correct invocation 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, so the schema provides no semantic burden and the baseline for 0-param tools is 4. The description explains what the output contains, which is the relevant semantic information here.

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

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

States a specific verb and resource: list all delivery services in CourierHUB's Russian network, and enumerates the content dimensions (what can be transported, pay frequency, schedule, rating, cities). The phrase 'Начните отсюда, чтобы узнать slug сервиса' clearly frames its role and distinguishes it from singular get_service and rate-specific siblings.

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

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

Explicitly says 'Начните отсюда' for getting slugs used by other tools, and tells the agent that rates are not here, redirecting to get_city_rates and calculate_income. This is direct when-to-use / when-not-to-use guidance with named alternatives.

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

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

Annotations already declare readOnlyHint: true, so the description does not need to restate that. It adds valuable context by describing the fallback behavior when no service is recruiting in the city, including that it 'честно говорит об этом' (honestly says so) and shows editorial-rated options. This goes beyond annotations and informs the agent of an important conditional outcome.

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 concise yet information-dense, front-loading the purpose, then explaining inputs, outputs, and the edge case. Every sentence serves a purpose, and the structure flows logically from what the tool does to how it behaves in specific scenarios. 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?

The description covers the core inputs, outputs, and a key edge case, which is sufficient for a read-only recommendation tool. It does not explicitly mention the optional city parameter's effect on country-wide selection, but that is documented in the schema. The lack of an output schema is mitigated by describing the return structure (main recommendation, alternative, rule). Overall, it is complete for the tool's complexity.

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

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

Schema coverage is only 25% (only city has a description), but the description explicitly maps the three main parameters to their meanings: transport (foot, bike, car), time (fulltime, parttime, flexible), and priority (income, payout, easyStart). This directly compensates for the sparse schema and clarifies the enums, enabling correct invocation. The city parameter is covered by the schema's default behavior note.

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 verb ('Подбирает' = selects) and resource ('сервис'), and specifies the input format (three quiz answers) and output (recommendation, alternative, rule). It distinguishes itself from siblings like find_services by emphasizing the quiz-driven, rule-based selection process, making the tool's unique role 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 explains that the tool is used with three quiz answers, which implies when to call it, but it does not explicitly mention alternatives or when not to use it. There is no guidance on how it differs from find_services or get_service, leaving the agent to infer the use case. The context is clear but exclusions are absent.

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?

Adds substantial behavioral detail beyond the readOnlyHint: stemming, synonym and typo handling, explicit return fields, and a clear statement that full text is not included and should be retrieved via markdownUrl. No contradiction with annotations.

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

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

Three purposeful sentences, each earning its place: main action first, algorithm behavior second, return format and caveat third. No fluff and well front-loaded.

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

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

With no output schema, the description covers the essential return values, algorithm behavior, and the absence of full text, which is sufficient for a simple search tool. Limit semantics and pagination are unspecified, but are minor 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?

Explains query semantics (word stemming, synonyms, typos), meaningfully enriching the otherwise undocumented query parameter. It does not describe limit's purpose, but the schema's min/max and the parameter name make it largely self-evident.

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

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

States a specific action ('search blog articles') and resource ('статьям блога'), clearly distinguishing it from sibling tools that focus on services, cities, and terms. The title 'Поиск по блогу' reinforces the scope.

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

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

Implies usage context by comparing the algorithm to the site search line and describing exactly what is returned. It does not explicitly name alternative tools or exclusion conditions, but sibling tool names make the selection unambiguous.

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