uis_list_indicators

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

Annotations already cover readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so safety is handled. The description adds real value beyond that: the scale of the catalog, the concrete indicator-prefix categories, and notably a warning that NERA.*, XUNIT.* and PTR.* prefixes do not exist at the source, which prevents wasted queries. It does not cover pagination or rate 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?

Purpose is front-loaded in the first line, followed by scope, then the category reference block. The category list is long but earns its place as search fodder; the parenthetical about which prefixes were removed from the list is slightly noisy bookkeeping an agent does not strictly need.

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?

Safety traits come from annotations and the return shape is covered by an output schema plus a one-line mention of a Markdown indicator list, so the description need not explain returns. For a single-parameter, read-only catalog tool this is essentially complete, with only filter behaviour (how theme and search combine) left unspecified.

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?

Reported schema description coverage is 0% at the top level (the single 'params' object carries no description), so the description partially compensates by enumerating theme, search and limit and marking the first two optional. It adds no syntax, format or value guidance beyond what the nested property descriptions already state, so it is minimum-viable rather than enriching.

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 opening sentence gives a specific verb and resource (list available UIS indicators) and the follow-up quantifies scope (over 4,000 indicators across education, science, culture, communication). An agent can distinguish this exploration/catalog tool from siblings like uis_get_education_data or uis_compare_countries without opening the 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?

'Diese Funktion dient zur Exploration und Indikatorsuche' implies the when-to-use case (discovering indicator IDs before fetching data), which is a reasonable implicit signal. However, it never names an alternative tool or states when not to use it, so the routing decision against uis_get_education_data is left to inference.

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