Lab4U

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

Annotations already declare readOnlyHint, idempotentHint and a closed world, so the safety profile is covered. The description adds genuinely new behavioral content: the matching rule (at least 2 from the list, at most 10 extra), and that it surfaces what is unavailable in the city and what cannot be ordered separately. It does not mention failure modes when nothing matches, which keeps it from a 5.

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

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

Four short sentences, front-loaded with the action and its matching rule before the routing condition. Every sentence carries information, though the 'включает хотя бы 2 анализа ... добавляет не больше 10' clause is dense enough that a reader may need to re-read it.

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 an output schema present and full schema coverage, the description only needs to explain intent and matching logic, which it does. What is missing is the behavior when no suitable complex exists, but the core is complete for a read-only check tool.

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

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

Schema description coverage is 100%, with test_ids and location_id both documented in the schema, including the 1–20 item bound and the pointer to lab4u_cities. The description only implicitly references these inputs ('список анализов', 'недоступно в городе') and adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Проверяет список анализов ... перед сборкой корзины') and then spells out the actual behavior: it finds the best matching ready-made complex containing at least 2 tests from the list and adding no more than 10. That is far more concrete than a name restatement, though it never explicitly contrasts itself with siblings like lab4u_tests_search or lab4u_test_details.

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

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

It states the triggering condition plainly: call it when the user has a concrete list of tests, including one prescribed by a doctor. That is a clear usage context, but there are no exclusions or named alternatives telling the agent when to prefer lab4u_tests_search or lab4u_cart_link_create instead.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation profile is covered. The description adds beyond that: it returns a link, and the agent is told to surface unavailable-in-city and incompatible tests from the response, which is real post-call behavior. It stops short of noting link lifetime, idempotency implications, or retry behavior, so not a 5.

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

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

Three short sentences, front-loaded with the core operation, then the trigger condition, then the prerequisite and post-call duty. No sentence is 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 values needn't be described in full, yet the description still tells the agent what to do with response content (report unavailable/incompatible tests). Combined with the trigger and prerequisite, an agent has everything needed to call this 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 coverage is 100%; both parameters are documented with their source tools (lab4u_tests_search, lab4u_cities). The description repeats the 1-20 cap that maxItems/minItems already encode and adds no further format or edge-case detail, so baseline 3 applies.

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

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

States a specific verb and resource (assembles a cart from a list of test IDs), names the scope limit (up to 20), the city dependency, and the return value (a link). The purpose is distinguishable from siblings like lab4u_basket_check without opening any schema.

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 when to call ("when the user has agreed to the list") and names an alternative plus its triggering condition (check via lab4u_basket_check first if the user had a specific list). Both the positive and the prerequisite case are spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is the entry-point call whose output feeds location_id into downstream calls, and it specifies the correct response when no city matches.

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, front-loaded with the purpose and positioned as the first call in the workflow. Every sentence carries actionable information with no filler.

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

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

For a single optional-parameter lookup with an output schema and full annotation coverage, the description provides everything needed: what it returns conceptually (location_id), when to call it, and the no-match handling.

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

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

Schema coverage is 100% and the name parameter (partial city match, omit for full list) is fully documented in the schema. The description adds no parameter-level detail beyond that, so baseline 3 applies.

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

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

States a specific verb+resource: lists the cities where Lab4U tests are available. The resource (cities/locations) is clearly distinct from the sibling tools (basket, cart link, test details, test search), though it does not explicitly name them.

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

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

Gives explicit usage guidance: 'Вызывай первым' (call this first) to obtain the user's location_id, plus a fallback instruction when the city is absent. No alternatives are named, but the sibling tools are different resources, so routing 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?

Annotations already establish read-only, idempotent, non-open-world behavior, and the description adds useful behavioral context by spelling out what details are returned: availability, turnaround, weekend operation, gender restrictions, marker list, and preparation link. It does not discuss auth, rate limits, or edge cases such as unavailable tests, but it adds meaningful scope beyond the annotations.

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

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

It is compact and front-loaded: the first sentence states what details are available, and the second states when to call it. Every clause adds useful scoping or trigger information without repetition.

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

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

Given the tool's low complexity, full schema coverage, existing output schema, and annotations covering safety behavior, the description is complete enough to select and invoke the tool correctly. It explains the returned detail scope and usage trigger, while parameter provenance is handled in the 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 100%, so both parameters are already documented: test_id from lab4u_tests_search and location_id from lab4u_cities. The description reinforces the city/test scope but does not add syntax, format, or selection guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names a specific resource and scope: details about one test in a city, and enumerates the concrete attributes returned (availability, turnaround time, weekend operation, gender restrictions, included markers, preparation-rules link). This clearly separates it from the search/list sibling lab4u_tests_search, especially with the input schema noting test_id comes from that search 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?

It gives an explicit trigger: call when the user asks about a specific test or needs to compare similar ones. It does not name when-not-to-use conditions or explicitly route broad search to lab4u_tests_search, but the usage context 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses non-obvious result behavior: complexes are returned first, each item carries a "нашлось" label and complex composition, and omitting location_id hides availability and timing. That is useful context the annotations cannot convey, though nothing is said about result limits or ordering beyond complexes-first.

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 purpose and searchable fields, then moves to invocation advice and result interpretation, with no filler sentences. It does repeat the location_id requirement already stated in the schema, a minor 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?

With an output schema present, return values need no explanation, yet the description adds result ordering and the meaning of per-item labels, which aids correct selection. For a two-parameter read-only search tool, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and both parameters are already documented in the schema, including the 1–10 array bound and the location_id reference to lab4u_cities. The description's contribution is mainly the clarification that queries should be discrete keywords rather than a full phrase, which is already implied by the schema's example. Baseline 3 applies.

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

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

The description states a specific verb and resource ("Поиск анализов и комплексов Lab4U") and enumerates what the keywords can match: name, abbreviation, indicator, or topic. It is clearly a search tool, but it never names lab4u_test_details as the drill-down alternative, so sibling differentiation is left implicit.

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 concrete guidance: pass all needed keywords at once rather than the user's whole phrase, and location_id is mandatory because otherwise availability and timing are invisible. It also says to use the "нашлось" label and complex composition to pick the right item. What's missing is an explicit statement of when to reach for a sibling like lab4u_test_details instead.

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