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

Annotations already provide readOnlyHint and idempotentHint. The description adds a meaningful behavioral detail beyond annotations: contact data are hidden by default and only appear when the parameter is explicitly set. This helps the agent avoid assuming full data will always come back.

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 core purpose, the second surfaces an important default behavior. No filler or redundant 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?

For a low-complexity tool with an output schema, rich annotations, and only two parameters, the description is sufficient. The key gotcha—hidden contact data—is disclosed, and the schema covers parameter syntax and defaults.

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 50%, so the description should compensate. It does clarify the behavior of pokaz_dane_kontaktowe, but it adds little semantic meaning for id_klienta beyond what the property name already implies. Partial compensation only.

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: 'Pobiera dane jednego klienta' (retrieves data of one client). This clearly distinguishes it from sibling tools, which target offers, agents, locations, dictionaries, calendar events, investments, and offices.

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 clear: call this tool when you need data for a single client. It does not name alternatives explicitly, but none of the sibling tools appear to compete for the same job, so the lack of exclusionary guidance is minor.

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 cover safety via readOnlyHint, idempotentHint, and destructiveHint=false. The description adds one useful behavioral constraint—the response is limited and omits contact data—but does not describe pagination, sorting, or result availability. This is helpful but not rich behavioral 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 one focused sentence with no filler. It front-loads the action and resource, then states the key limitation. Every phrase earns its place and matches the low complexity of the tool.

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 list operation with full schema coverage, an output schema, and safety annotations, the description is nearly sufficient. It clearly states the tool returns a limited agent list without contact data, though response details are mostly delegated to the 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 coverage is 100%, and the sole 'limit' parameter has a complete schema description: 'Maksymalna liczba rekordów w odpowiedzi.' The description's phrase 'ograniczoną listę' loosely reflects the limit concept but adds no new parameter semantics beyond what the schema already provides.

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 ('Pobiera' - retrieves) and resource ('listę agentów'), and adds a distinctive scope: a limited list without contact data. This differentiates it from sibling list tools such as esticrm_lista_ofert, esticrm_lista_biur, and esticrm_lista_inwestycji, and from tools that would expose contact 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?

The intended use is implied: get a bounded list of agents when contact details are not needed. However, it does not explicitly name alternatives, give when-not-to-use conditions, or explain how it differs from sibling tools beyond the resource type.

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 the tool as read-only, idempotent, open-world, and non-destructive, so the safety profile is well covered. The description adds only the mild behavioral trait that the returned list is limited/restricted, without detailing ordering, default cap, pagination, or completeness; this 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?

The description is one short sentence with the key information front-loaded: action, resource, and limiting behavior. There is no wasted wording, and the size is appropriate for a one-parameter read-only tool.

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, the description together with the rich annotations, fully documented limit parameter, and presence of an output schema is enough for an agent to call it correctly. Nothing critical is missing for this low-complexity operation.

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?

There is exactly one parameter, 'limit', and the input schema documents it fully with a default, minimum, maximum, and a clear description. The tool description adds no parameter-specific meaning beyond the vague word 'ograniczoną', so the schema carries the burden; 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 action ('pobiera' – retrieves) and a distinct resource ('listę biur' – list of offices), and signals that the result is limited. This differentiates it from sibling list tools such as lista_ofert, lista_agentow, and lista_inwestycji by resource.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance, and it does not mention any alternatives or exclusions relative to the sibling tools. Usage must be inferred entirely from the resource name and the generic verb, so the tool does not help an agent decide between this and other list tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that the returned list is 'ograniczoną' (limited), which is a useful behavioral hint, but does not disclose much beyond that and the schema already conveys 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource.

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 list tool with output schema and safety annotations, the description is mostly adequate. But it lacks explicit parameter semantics for 'fraza' and any usage context relative to sibling list tools, leaving an agent to infer important calling details.

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

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

The schema describes 'limit' explicitly, and the description's mention of filtering gives some clue that 'fraza' is a filter parameter. However, the description does not clarify how 'fraza' behaves (e.g., partial match, which fields are searched), so it only marginally compensates for the missing schema description on that 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 uses a clear verb ('Pobiera' - retrieves) with an explicit resource ('listę inwestycji'), and the resource makes it distinguishable from sibling tools like esticrm_lista_ofert. However, the phrase 'lub filtruje ograniczoną listę' introduces some ambiguity about whether this returns a bounded subset or filters by criteria.

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

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

The description gives no guidance on when to use this tool versus sibling tools, no mention of alternatives, and no exclusions. The intended use is only implied by the name and resource, not explicitly stated.

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

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

The description repeats the read-only behavior already declared by readOnlyHint=true, which adds little. It does add useful behavioral context by describing the result as 'ograniczoną, stronicowaną listę', indicating pagination and a bounded result set. No contradiction with annotations 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 two short sentences, front-loaded with the core action and scope. It contains no filler or unnecessary detail, though the read-only statement is somewhat redundant with the annotations.

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 paginated list, the description covers the basic invocation needs, and the output schema can supply return-shape details. It is less complete as a standalone guide because it does not clarify when to choose this list over sibling offer-related 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?

The schema documents 'limit' but not 'strona', and the description's mention of pagination helps hint at the meaning of 'strona'. However, the description does not explicitly explain the page parameter or its relationship to the list, leaving some inference required.

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: 'Pobiera ... listę ofert' (retrieves a list of offers), and adds that the list is limited and paginated. It is clear, but it does not explicitly distinguish itself from siblings like esticrm_oferty_klienta or esticrm_szczegoly_oferty.

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

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

The description gives no guidance on when to use this tool versus alternatives. It conveys only what the tool does, not when it should be preferred over esticrm_oferty_klienta or esticrm_lista_inwestycji.

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, idempotentHint, and destructiveHint=false, which covers the safety profile. The description adds useful behavioral context by saying the list is 'ograniczona' and filtered to one client, but does not disclose other behaviors such as pagination or response ordering. With strong annotation coverage, this 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?

The description is a single concise sentence with no filler and the key limitation is front-loaded. It is not overlong, though it could have added a sentence about alternatives without becoming verbose.

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, two-parameter retrieval tool with a rich annotation set and an output schema, the description is largely sufficient. It communicates the core purpose and scope, while schema and annotations carry the remaining details. The only clear gap is the lack of explicit sibling differentiation.

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 50%, so the description must compensate for the undocumented `id_klienta` parameter. It partially does by explaining that the offers belong to one client. The `limit` parameter is already well covered by its schema description, so no additional explanation is needed there.

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, 'Pobiera' (fetches), names the resource, 'ograniczoną listę ofert', and clearly scopes it to 'przypisanych do jednego klienta'. This distinguishes it from sibling tools like the general list of offers or offer details, even though no sibling is named.

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 you need a limited list of offers for one client. However, it gives no explicit guidance about when not to use it or which sibling should be preferred instead, such as esticrm_lista_ofert for unfiltered offer lists.

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 readOnly, openWorld, and idempotent behavior, so the bar for the description is lower. The description adds a valuable behavioral limitation: the tool only exposes three fixed dictionaries and cannot be used as a generic API endpoint, which is exactly the kind of nuance an agent needs.

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

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

Two concise sentences, front-loaded with the primary action and followed by one necessary constraint. There is no filler or repetition of the title or annotations.

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 an output schema and rich annotations, the description is nearly complete: it identifies the required parameter's domain and an important safety boundary. The only meaningful gap is the undocumented optional 'nazwa' parameter, which is not required for a valid call.

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

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

With 0% schema description coverage, the description must carry the parameter burden. It maps the enum values of 'rodzaj' to the three dictionaries, but it says nothing about the optional 'nazwa' parameter, 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 opens with a specific verb and resource: 'pobiera' one of three dictionaries, and it explicitly enumerates them (oferty, mapowanie_ofert, systemowy). It also distinguishes itself from a generic API-call tool by adding the constraint that it cannot invoke an arbitrary API path.

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 only implied: an agent should call this when it needs one of the three named dictionaries. The description includes a useful 'when-not' ('Nie pozwala wywołać dowolnej ścieżki API'), but it does not mention alternatives or explain when a sibling tool would be 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?

Annotations already declare this a read-only, idempotent, non-destructive operation, so the description is not required to restate safety. It adds only the calendar-identification detail; it does not disclose extra behavior such as overlap semantics or result handling, though the presence of an output schema reduces that need.

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

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

One front-loaded sentence carries the full purpose without extraneous content. It earns its place and does not repeat schema data.

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 availability check with complete annotations and an output schema, the description is nearly sufficient. It could be slightly stronger with an explicit note on when to prefer this over the calendar-events sibling, but nothing essential for invoking the tool 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 schema leaves 'kalendarz' undocumented except for maxLength; the description compensates by indicating it is the calendar identified by the agent's email address. The od/do time-range parameters are already described in the schema, so the description's contribution is concentrated where it is needed.

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 ('Sprawdza dostępność') and names the resource ('terminu w kalendarzu... adresem e-mail agenta'), making the tool's function unambiguous. It is distinct from siblings like esticrm_wydarzenia_kalendarza, which would list calendar events rather than check availability.

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 clearly implies the tool is for checking availability in an agent's calendar, but it gives no explicit when-to-use guidance or exclusions and does not point to alternatives such as esticrm_wydarzenia_kalendarza. Usage context is inferred from the purpose rather than stated.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description ('Pobiera' — fetches) is fully consistent with them, so there is no contradiction. The description adds no behavioral context beyond the annotations — no return-format, error, or availability notes — but for a simple read operation the annotated safety profile covers the main concerns. Adequate but unexceptional.

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?

A single, grammatically simple sentence that front-loads the action and stops. There is zero filler, and the length is appropriate for a one-parameter read-only tool. Every word 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?

With one required parameter, an output schema present, and annotations carrying the read-only/idempotent/non-destrucive profile, the description covers the essentials for invoking this tool correctly. The only real gap is routing guidance versus the sibling offer tools, which belongs to the usage dimension. For the tool's low complexity, 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?

Schema description coverage is 0%, so the description must compensate, and it only re-states what the parameter name `id_oferty` already conveys: the identifier selects the offer. No extra semantics are added — no format guidance for the string/integer union, no indication of where the ID comes from, and no behavior for unknown IDs. The parameter is self-explanatory by name, but the description adds essentially nothing 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 uses a specific verb ('Pobiera' — fetches) with a specific resource ('szczegóły jednej oferty' — details of one offer) and the access path ('po jej identyfikatorze' — by its ID). This clearly signals a single-record lookup and implicitly contrasts with the sibling list tools such as `esticrm_lista_ofert`, though no sibling is explicitly named. Clear and specific, but the sibling differentiation is implicit 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?

No when-to-use, when-not-to-use, or alternative tool is mentioned anywhere in the description. An agent must infer that this tool is for retrieving one offer when the ID is already known, and that browsing or filtering belongs to `esticrm_lista_ofert` or `esticrm_oferty_klienta`. The usage context is implied by the tool's nature but never stated, with no exclusions or prerequisities.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by saying the result is 'ograniczoną listę' (a limited list), which hints at result-set boundaries, and clarifies that the calendar is identified by an agent email.

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?

A single front-loaded sentence states the verb, resource, and key scoping detail without filler or repetition. Every word contributes meaning.

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 is present and the annotations cover the safety profile, so those aspects do not need to be restated. The description adequately identifies the calendar and result-set nature; the date-range and limit parameters are documented in the schema, making the definition sufficient 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?

Schema descriptions already cover 'od', 'do', and 'limit'. The description adds value for the undocumented 'kalendarz' parameter by indicating that the calendar is specified through the agent's email address, and 'ograniczoną listę' maps to the limit behavior.

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 ('Pobiera' - fetches) and names the resource precisely: a limited list of events from a calendar indicated by the agent's email address. This clearly distinguishes it from sibling tools, none of which are described as calendar-event retrieval.

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 is implied: use when you need a bounded list of events from a specific agent's calendar. The description gives useful context by specifying the calendar is selected via the agent's email, but it does not name alternatives or state when not to use this tool.

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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the search uses a short phrase and limits results, but does not disclose behavior like partial matching, case sensitivity, or empty-result handling. With annotations handling the main risk disclosure, this 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?

A single concise Polish sentence conveys both the action and the limit behavior without wasted words. Information density is high and the most important detail (search by phrase) comes first.

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

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

For a simple two-parameter search tool with an output schema and robust annotations, the description is nearly complete. The main gap is the absence of any note on where location data comes from or how it connects to related entities, but that is not essential for invoking the 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 only 50%: only limit has a description. The description partially compensates by indicating fraza is a short phrase used for searching and that results are limited, but it doesn't elaborate on matching semantics or expected input format. This is enough to make both parameters understandable, but not a strong 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 states a specific verb and resource: 'Wyszukuje lokalizacje' (searches locations) by a short phrase with a result limit. This clearly distinguishes it from its siblings, which operate on different entities (offers, clients, agents, investments, offices).

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 context is clear: an agent should call this when it needs to find locations from a short text phrase. No sibling tool provides a similar location search, so explicit exclusion of alternatives is unnecessary; however, the description does not state when not to use it or how it relates to list_inwestycji or list_biur.

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