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

No annotations are provided, so the description carries the disclosure burden. It adequately covers the key behavioral traits: the operation is cheap ('один дешёвый запрос'), does not download results, and returns the full count ('полное число объявлений'). It does not overpromise or hide side effects, and the read-only nature is sufficiently implied.

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, each earning its place: what it does, when to use it, and what it returns. The core behavior is front-loaded, and there is no redundant repetition of schema 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?

Despite the high parameter count, the schema fully documents all parameters, so the description does not need to enumerate them. It provides the missing contextual piece: the return value ('total') and the operational guarantee that this is a cheap count rather than a data-fetching call. For a count tool, this is complete enough for an agent to select and invoke 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 description coverage is 100%, and all 37 parameters already have meaningful descriptions in the schema. The tool description adds no parameter-level detail beyond the generic 'по фильтру', but it does not need to because the schema fully documents each parameter. Baseline 3 is 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 states a specific verb and resource: 'Считает результаты по фильтру' (counts filtered results) and explicitly distinguishes itself from fetching tools by saying 'не выкачивая их' (without downloading them). It clearly communicates that this is a count-only counterpart to search-like tools, and states the exact return value ('total').

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: use it to 'проверить осмысленность критериев' (validate criteria) and 'сравнить варианты фильтра' (compare filter variants). It implies the alternative is fetching results with search/listing, but does not name those alternatives explicitly 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?

No annotations exist, so the description carries the burden. It discloses the data scope, the id-bearing entries, the autocomplete-like behavior of query, and that query returns a ready city/district/urban bundle. It does not specify the output shape for the city-only or no-parameter case, though the schema's city parameter partially covers that.

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 dense sentences with no wasted words. The core purpose is front-loaded, the alternative tool is named, and the query-mode behavior is stated last without 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 simple two-optional-parameter read-only reference tool with no output schema, the description covers the primary usage modes and the sibling distinction. It leaves a little ambiguity about the exact response shape when called with no parameters or only city, but the input schema's city description covers the no-parameter default, so the gap is minor.

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%, so the baseline is 3. The description adds real value beyond the schema by explaining what the query parameter actually produces (site-like autocomplete returning a ready-made city/district/urban bundle) and positioning city as a browsing action. This lifts it above the baseline.

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

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

The description clearly identifies the tool as a location reference for cities, districts, and subdistricts with ids. It also names the core actions (browse available locations, disambiguate) and explicitly contrasts itself with search(), which resolves names, so an agent can tell them 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?

It gives an explicit rule: search() is for passing names that it resolves itself, while geo is for viewing what's available or removing ambiguity. This is a direct when-to-use versus alternative 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 provided, the description carries the full burden of explaining behavior. It makes clear that this is a read-only-like instruction retrieval tool, explains what each instruction covers, and frames it as a preliminary step. It does not mention output format or error behavior, but for a simple skill-fetch tool the behavioral disclosure is adequate.

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: it opens with the core purpose, then details the two enum options, and closes with a clear usage directive. Every sentence contributes information, and there is no filler or repetition of schema fields.

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 simplicity (one required enum parameter, no output schema, no nested objects), the description fully equips an agent to call it correctly. It specifies both allowed parameter values, explains their meaning, and states exactly when the tool should be invoked.

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 the enum values with only a terse 'имя инструкции' label, while the description explains what each enum value actually contains: 'apartment-search' covers how to decompose criteria and sequence tools, and 'criteria-coverage' covers what livo.ge handles approximately or not at all. This adds essential meaning beyond the schema.

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

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

The description states a clear verb and resource: 'Возвращает инструкцию' (returns an instruction), and goes further to enumerate the two specific instruction names with their content. This clearly distinguishes get_skill from sibling data-access tools like search or listing, which return actual data rather than guidance.

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 an explicit usage context: 'Вызывай перед сборкой многокритериального поиска' (call it before assembling a multi-criteria search). It does not explicitly list when not to use it or name alternative tools, so it stops short of a perfect 5, but the guidance is specific and actionable.

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 it does disclose useful traits: phone is 'частично скрыт' and created_at is the true publication date, which is a meaningful clarification beyond a generic timestamp. It does not explicitly label the operation as read-only or cover error behavior, but for a simple card-fetch tool the key behavioral facts are present.

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 fluff: the first enumerates the card contents compactly, and the second highlights the unique created_at property. Every sentence earns its place and the key differentiator is front-loaded in the second sentence after the core resource definition.

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 output schema, the description does a good job of communicating what the agent will receive: a full listing card with a specified list of attributes, plus a note that phone is partially hidden and created_at is uniquely available here. The input parameters are fully covered by the schema, so the description does not need to repeat them. Missing explicit response-structure details are minor for a tool of this simplicity.

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 the schema already documents both id and with_similars. The description adds no parameter-level meaning beyond mentioning created_at, which is an output field rather than a parameter. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 resource: 'Полная карточка' followed by a field list (описание, удобства, координаты, этажность, состояние, кадастр, просмотры, телефон). It also differentiates from siblings by noting that created_at is 'единственное место, где она приходит явно'. However, it lacks an explicit action verb like 'return' or 'fetch', 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 'единственное место, где она приходит явно' explicitly tells an agent to use this tool when the real publication date is needed, which is a clear when-to-use signal. The enumerated field list also implies this is the tool for full listing details. It does not name sibling alternatives or give when-not-to-use exclusions, so it is not 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?

There are no annotations, so the description carries the disclosure burden. It usefully reveals that min_price arrives as a range in three currencies and that uuid selects a single project card. Still, it does not describe list-mode response shape, pagination behavior, or other output fields, so disclosure is only partial.

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, information-dense sentences with no filler. The most important distinction — separate dataset, not listings — is front-loaded, and each sentence contributes a distinct fact.

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 single-project mode and a key output quirk, and the schema documents all parameters. But there is no output schema, and the tool's list mode, default behavior, and the interaction of city/areas/page/limit are left implicit, so an agent has to infer significant context.

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 every parameter already has a description. The uuid behavior in the description largely repeats the schema's own uuid description, so it adds little new parameter-level meaning. The min_price note concerns the response rather than the input 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 names the resource ('проекты застройщиков'), uses the concrete verb 'возвращает' for the uuid mode, and explicitly states this is a separate livo dataset, not a subset of listings. This clearly distinguishes it from the sibling 'listing' 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 uuid sentence provides a clear conditional: use it to get a single project card. The 'not a subset of listings' statement also guides the agent away from the listing sibling. However, it does not address alternatives like count, search, or geo, or say explicitly when list mode is preferred.

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

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

With no annotations, the description carries the burden of explaining behavior, and it does disclose useful traits: dictionaries are split by estate, names are localized via LIVO_LOCALE, and amenities have stable keys. However, it does not mention whether the operation is read-only, how invalid groups are handled, or what the response shape looks like beyond the id->name mapping.

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: purpose first, then the estate-filtering behavior, then localization. Every sentence contributes actionable information with no filler or repetition of schema details.

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 reference-data tool with only two parameters and no output schema, the description covers the essential information: what is returned, estate applicability, and localization. It could still mention behavior when estate is omitted or how the locale is determined, but these are minor gaps given the low complexity.

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

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

The schema already covers 100% of parameter descriptions, so the baseline is 3. The description adds meaningful extra context by explaining that the dictionaries map IDs to names for filters, that most dictionaries are estate-specific, and that localized names depend on LIVO_LOCALE, which goes beyond the schema's basic field 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 clearly identifies the resource as id-to-label dictionaries for filter parameters, giving concrete examples such as conditions, project_types, and metro_stations. It lacks an explicit verb like 'return' or 'get,' but the purpose is otherwise unambiguous and distinct from the broader search/list sibling 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?

The description states when to use the tool: for filters that accept only IDs, and directs the caller to pass estate to get applicable values. The schema additionally gives an explicit exclusion and alternative by noting that locations are not included and should be handled by geo(), providing clear when/where-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 provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple summary by revealing critical behavior: partial results requiring returned/total comparison, prices returned in GEL/USD/EUR, the distinction between age_days/published and updated, and applied_filters as an API echo. These are non-obvious traits that materially affect how the agent interprets results.

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

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

The description is compact and every sentence earns its place. It front-loads the core purpose, then adds high-value caveats about partial results, currency behavior, date semantics, and API echo. No filler or repetition of schema details.

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 40 parameters and no output schema, the description is reasonably complete: it covers the essential response caveats and field semantics. However, it does not describe the overall response shape or pagination mechanics beyond the returned/total hint, and it leaves the agent to discover any additional output fields from actual usage.

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 the baseline is 3. The description does not add much about individual input parameters, but it does clarify related output semantics such as age_days, updated, and applied_filters. The schema already documents all 40 parameters well, so the description does not need to compensate.

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 and resource: 'Ищет объявления на livo.ge' (searches listings on livo.ge). It is specific enough to understand the tool's core action, but it does not explicitly differentiate itself from siblings like listing or count.

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 what the tool does but gives no guidance on when to prefer search over alternatives such as listing, count, or geo. There is no explicit when-to-use or when-not-to-use context, so the agent must infer usage 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.