Числата

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the modest facts that results are yearly averages and optionally broken down by sector or sex; it says nothing about which years exist or output shape, which is acceptable but thin given the low burden.

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 with the core measure stated first and the optional dimension second; nothing is padded. The semicolon-clause phrasing is slightly compressed but still readable.

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 two-parameter read-only lookup with no output schema, the definition is workable but leaves gaps: the available year coverage and the requirement to source the activity slug from list_activities are not surfaced in the description. An agent can still call it correctly because the schema carries those constraints.

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 both parameters are already documented and the baseline is 3. The prose paraphrase of the breakdown values ('public/private sector or men/women') adds no meaning beyond the enum and even omits the 'total' default, so it does not raise the score.

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 measure (average gross monthly wage), a time dimension (by year), and the dimension of aggregation (economic activity), which distinguishes it from siblings like get_occupation_wages and get_region_wages by resource axis. It never names those siblings explicitly, so the differentiation is implicit 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?

Usage is implied: reach for this when you want wage data keyed to an economic activity, optionally split by sector or sex. There is no explicit when-not guidance and no pointer to alternatives, and the dependency on list_activities for a valid slug appears only in the schema, not the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses what the call actually yields (title, period, source, dimensions with codes and labels), which is genuinely useful since there is no output schema; it does not mention error behavior for unknown dataset ids, keeping it below 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?

It is a single compact sentence with no filler, and the payoff (the get_dataset_data filters) is front-loaded at the end of the clause. The trade-off is that it is a noun phrase with no verb, making the operation slightly less immediately parseable than a purely declarative sentence.

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 lookup with no output schema, the description does cover the returned fields and the workflow link to get_dataset_data. However, it does not say what happens when a dataset_id is invalid or what the dimension codes/labels structure looks like, which matters given the absence of an 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 single dataset_id parameter is already documented in the schema with an example (nsi-1169) and its provenance from search_datasets. The description adds no further meaning about the id format or lookup behavior, 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 names the resource (a dataset's metadata: title, period, source, dimensions with codes and labels) and implicitly the operation (fetch that metadata). It distinguishes itself from the sibling get_dataset_data by framing itself as the source of that tool's filters, though it never uses an explicit verb like 'retrieve' or 'get'.

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

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

It gives clear usage context: this is what you call to obtain the dimension codes and labels needed to build get_dataset_data filters, which effectively routes the agent from search_datasets to get_dataset to get_dataset_data. It does not state any when-not-to-use condition or an explicit alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact: a hard cap of at most 2000 rows. It does not say whether hitting that cap truncates silently or errors, and it says nothing about pagination or response shape.

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 clauses, front-loaded with the resource and scope, then the row limit. Nothing is redundant and every clause carries information the agent needs.

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 four parameters, a nested filters object, and no output schema, the description should say more about what a returned row looks like and what happens when the 2000-row limit is exceeded. It does correctly cover the input side and the size constraint, so it is adequate but with clear gaps on the output/truncation side.

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 all four parameters including the nested filters map are already documented with patterns and examples. The description reinforces the meaning of filters (dimension codes obtained from get_dataset) and of period, but adds no format details, defaults, or constraints 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?

States the specific resource (dataset values) and the two things that scope it: dimension codes and period. It also points at get_dataset as the source of the codes, which separates it from the sibling that only describes datasets. It falls short of a 5 only because it never names a sibling alternative for retrieving values differently.

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 parenthetical '(from get_dataset)' implicitly tells the agent to fetch dimension codes first, which is real workflow guidance. There is no explicit when-to-use/when-not statement, no mention of prerequisites such as needing valid codes, and no routing to any sibling.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the aggregation scope (every party/candidate, and the geographic granularity), but says nothing about ordering, empty/partial results, or whether figures are provisional.

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 compact sentence with no filler and the aggregate content front-loaded. It is fragmentary rather than ungrammatical, and nothing is wasted, though it reads more like a label than a complete instruction.

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 three-parameter read tool with full schema coverage and rich annotations, the essentials are covered and the description hints at the return shape (votes and shares per party/candidate per unit). It still omits whether a single call returns one unit or all units, and whether totals/turnout accompany the party rows.

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%, including the level enum and the unit slug format with an 'omit for all' rule, so the schema carries parameter meaning. The description's 'in the country, abroad or by oblast' merely echoes the level enum rather than adding semantics such as whether unit accepts multiple oblasts or is ignored when level is country.

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: votes and shares per party/candidate, broken down by country, abroad, or oblast. That is clearly distinct from list_elections, though it never names the sibling or states the verb 'retrieve results for an election' 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?

Usage is only implied: it is evidently the tool to call for result figures, but there is no explicit when-to-use, no mention that election_id must come from list_elections (that hint lives only in the schema), and no stated exclusions versus other data 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 readOnly, idempotent and closed-world behavior, so the bar is lower. The description adds useful context beyond them: the bounded 265-municipality domain, accepted identifier formats, and the fact that a link to the municipality page is returned — important given there is no output schema.

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

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

A single dense sentence that front-loads the returned data and then the key formats. It is slightly crammed toward the end ('with the link to its page'), but 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 one-parameter, read-only, no-output-schema tool this covers the essentials: what comes back, and how to identify the municipality. Remaining gaps — case sensitivity, partial matching, unknown-name behavior, and the slug option — are 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, but the description goes further by giving concrete Bulgarian-script examples (Първомай, Столична), which is exactly the kind of hint an agent needs to format a Cyrillic `name` correctly. It does omit the slug option that the schema mentions, so it is not fully additive.

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 exact resource (one of 265 municipalities) and the exact payload (population, births, deaths by year) plus the lookup key formats. It is clearly distinguishable from siblings like get_region_wages or get_dataset, which cover different resources.

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 implicit: an agent can infer this is the tool for municipality-level demographic data, but the description never states when to prefer it over a related sibling or what to do if the name is ambiguous or unknown. There are no alternatives or exclusions named.

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 this as a read-only, idempotent, closed-world lookup, so the description's job is to add context — and it does: it discloses the NSI Structure of Earnings source, the four-year cadence (warning the agent not to expect annual granularity), and the default-to-latest behavior. It does not state currency, units, or geographic scope, which leaves a modest gap.

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 with no filler; the measure list and source are front-loaded and the default-year rule follows immediately. Every clause carries 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?

For a two-optional-parameter read tool with no output schema, the description covers source, frequency, measures, and the default-year rule. The main remaining ambiguity is the unit/currency of the wage figures and whether the data is national only, which an agent may need.

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 both parameters are already documented, including the sex enum. The description adds meaning the schema lacks: that omitting year returns the latest available survey rather than erroring, which changes how an agent should construct the call.

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 measure set (gross, median and net monthly wage by occupation class) and identifies the source survey. 'By occupation class' distinguishes it from siblings get_region_wages and get_activity_wages, though those siblings are not named 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?

The clause 'Without a year, the latest' gives clear guidance on how to call the tool when the optional year is omitted. There is no explicit statement of when to prefer this tool over get_region_wages or get_activity_wages, so alternative selection is only implied by the resource dimension.

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, closed-world, and non-destructive, so safety needs no explanation. The description adds genuine context beyond that: the temporal range (2008–), the two currency representations, and the inclusion of employee counts, which tells the agent what the payload contains.

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 sentence, front-loaded with the core measure, with every clause (time range, geography, currencies, employee counts) carrying distinct information. Nothing is redundant.

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 read-only lookup with no output schema, the description covers measure, scope, units, and payload contents well. It could note the return shape or ordering, but nothing essential to 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?

Schema coverage is 100% and the region parameter already documents its slug format and example values from list_regions. The description's phrase 'Bulgaria, a NUTS2 region or an oblast' reinforces the accepted geographic granularity but adds no syntax or constraint detail the schema lacks, 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 states a specific measure (average gross monthly wage), coverage start year (2008–), geographic scope (Bulgaria, NUTS2 region, or oblast), and units (euro and leva plus employee counts). The 'by region' framing implicitly separates it from get_activity_wages and get_occupation_wages, though those siblings are never 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?

Usage is only implied: an agent can infer this retrieves wage statistics for a given region. There is no explicit when-to-use versus get_activity_wages/get_occupation_wages, and the list_regions prerequisite appears only in the schema, not the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description adds that each entry carries a slug alongside the classification label, but says nothing about whether the list is exhaustive, ordered, or a static taxonomy — useful context that is missing.

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 short sentence with the key content front-loaded and no filler. Nothing could be removed without losing 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?

For a zero-parameter reference lister with a full annotation set and no output schema, stating the resource and that entries include slugs is close to sufficient. A note on ordering or on how the slugs feed the wage endpoints would close the remaining gap.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The sentence correctly implies an unfiltered full listing rather than a searched subset.

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 (economic activities), the classification systems involved (NACE sections, КИД-2008), and the payload (slugs), so an agent knows it returns a taxonomy reference list. It does not explicitly name the retrieval verb or contrast itself with list_regions/list_elections, but the resource is unambiguous.

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

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

There is no guidance on when to call this instead of a sibling, and no mention that the returned slugs are presumably the keys the wage tools (get_activity_wages) expect. The agent must infer the role of this tool from its name alone.

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, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description adds useful scope context by stating coverage starts in 1991 for parliamentary and 1992 for presidential elections, but it does not describe pagination, result volume, or ordering.

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 compact fragment covering both election types, their start years, and the returned fields, with no wasted words. It is front-loaded and scannable, though the verbless fragment style makes it read as a dataset blurb rather than a tool instruction.

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-optional-parameter read tool with rich annotations and no output schema, the description is adequate but minimal. It omits how this differs from get_election_results, which is the most important missing context given the sibling list.

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 enum is documented in the schema itself ('ns = parliament, pr = president'), which the description merely restates. With a single optional parameter fully documented, the baseline of 3 applies; the description adds nothing new about the 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 identifies the resource (parliamentary and presidential elections) and the fields returned (date, voters, turnout), but never states an action and does not distinguish it from the sibling get_election_results. An agent can infer this is a listing of election events, yet the boundary with the sibling tool is left ambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as get_election_results. The temporal scope hints at coverage but says nothing about when an agent should pick this tool over its sibling.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that entries carry slugs, which is the practically useful detail for chaining into other tools, but it omits that the list is static and unfiltered.

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 compact phrase with no filler, and the key facts (country scope, region counts, slugs) come first. It is efficient but borders on under-specification since no verb anchors the sentence.

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 lookup list this covers the essentials: geographic scope, the two hierarchy levels, and that slugs are included. However, with no output schema, the description should have stated more concretely what a returned item looks like and whether the hierarchy is flat or nested.

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 takes zero parameters, so there is no parameter semantics for the description to explain. Baseline 4 applies; nothing is missing on this dimension.

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 is a noun phrase with no verb: it names the resource contents (Bulgaria, 6 NUTS2 regions, 28 oblasts, slugs) but never states that the tool lists or returns them. Combined with the name list_regions an agent can infer intent, but the description itself only describes the subject matter rather than the action.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to any sibling such as get_region_wages or get_municipality. The agent must infer from the name alone that this is the reference list to call before using region-keyed 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 readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behaviour: it matches only against Bulgarian titles (not descriptions or English titles) and degrades to a full listing when no query is supplied.

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, zero filler, with the search scope front-loaded and the empty-query fallback as the closing clause. Nothing could be cut without losing 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?

With no output schema, the description never says what a hit looks like — whether it returns dataset IDs, titles, or fully-qualified identifiers the agent can feed into get_dataset. For a discovery tool that exists to produce arguments for other tools, that is a meaningful gap, though the search semantics themselves are complete.

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

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

Schema coverage is 100% and both enums are documented with descriptions, so the schema carries the parameter burden. The description echoes the Bulgarian-language hint already in the query property and adds no extra syntax or matching semantics beyond the schema 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?

States a specific verb and resource ("Find datasets") plus the scope: two named publishers and the domain list (population, income, prices, GDP…). The Bulgarian-title matching criterion and the no-query behaviour make it unmistakably a catalogue search rather than the get_dataset / get_dataset_data 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?

Gives a clear entry condition: free-text lookup when the user has words, and an explicit fallback ("Without a query, lists all of them") for browsing the whole catalogue. It stops short of naming the alternative for when an ID is already known (get_dataset), so the hand-off to siblings must be inferred.

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