ailibri — каталог ИИ-сервисов

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

No annotations exist, so the description carries the full behavioral burden. It discloses the sort order ('свежие сверху' / newest first), which is genuinely useful, but says nothing about pagination, default result count, filtering behavior, or whether adult/Russia filters are applied by default.

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 sort behavior front-loaded and no filler. It is efficient, though the brevity stems partly from under-specification rather than disciplined editing.

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?

A five-parameter browse tool with no annotations, no output schema, and 0% schema description coverage demands far more than one sentence. The description leaves filtering semantics, result shape, and pagination entirely unknown.

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% across five parameters (limit, category, only_free, include_adult, only_works_in_russia), and the description explains none of them. The agent receives no guidance on what these booleans do or how limit interacts with the sort order.

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 phrase names the resource (services of one catalog category) and a scope/sort qualifier ('fresh first'), which is more than a tautology. However, it is a bare noun phrase with no verb and nothing to distinguish it from siblings like list_categories or search_ai_tools, so the agent must guess the operation semantics.

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 statement of when to use this tool, when not to, or which sibling to prefer for category-based browsing versus searching. Usage is only weakly inferable from the name 'browse_category'.

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 full burden. It usefully discloses that results come from catalog relationship links rather than lexical matching and that this is 'надёжнее обычного поиска', which is a meaningful behavioral trait. However, it says nothing about permissions, result formatting, empty-result behavior, or how the limit is applied.

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?

Front-loaded with the core purpose, followed by example queries and a mechanism note. Efficient, though the trailing parameter note reads like an inline schema gloss rather than prose and could be trimmed or folded more cleanly.

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 read-only lookup tool with no annotations and no output schema, the description conveys purpose and input semantics adequately but omits what a result looks like (list of similar services?) and omits the limit parameter entirely. Enough to call it, but not 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 description coverage is 0%, so the description must compensate. It does explain the required 'name' parameter well (service name, alias, or ailibri card link), but the 'limit' parameter (default 8) is never mentioned, leaving half the parameters undocumented in both schema and description.

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 ('чем заменить конкретный сервис: аналоги и похожие') and explicitly distinguishes itself from ordinary keyword search ('Работает по связям каталога, а не по словам'), effectively separating it from the sibling search_ai_tools. An agent can tell what this returns and how it differs from a search tool without opening either 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?

Concrete trigger phrases ('аналог Notion', 'чем заменить Midjourney', 'альтернатива Photoshop') give clear when-to-use context. It also hints at the mechanism difference versus keyword search, but does not explicitly name search_ai_tools as the fallback for non-alternative queries or state exclusions, so it stops short of full routing 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?

No annotations are provided, so the description carries the burden. It discloses a good deal about the returned payload (price, Russia access, limitations, ratings, similar services), which is useful behavioral context, but says nothing about permissions, rate limits, or behavior on an unresolved/invalid identifier.

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 compact sentence enumerating the card contents, followed by the parameter explanation. It is front-loaded and contains no filler, though the comma-separated feature list is dense.

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 usefully summarizes the return contents and documents the only parameter, which is a reasonable minimum for a single-argument lookup. It is still missing when-to-use guidance and error/fallback behavior.

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 0% and the schema gives the single parameter no description, so the description must compensate. It does add real meaning by stating the parameter accepts a name, an alias, or a link to an ailibri card, but gives no format examples or guidance on ambiguity.

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

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

States a specific verb+resource (retrieve the full card of an AI service) and enumerates the card's contents, so the agent knows roughly what comes back. It does not explicitly say how it differs from search_ai_tools or find_alternatives, though the detail-view framing is implicit.

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

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

There is no statement of when to use this tool versus siblings like search_ai_tools (discovery) or find_alternatives (comparison). Usage is only inferable from the fact that it takes a single identified service.

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 are provided, so the description carries the full burden. It discloses only that entries include a card count and gives no behavioral traits (read-only nature, pagination, ordering, auth needs, locale/language of results). For a bare listing endpoint this is a real 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?

A single front-loaded sentence with zero filler. For a no-argument listing tool nothing more is structurally required.

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?

Complexity is minimal (zero params, output schema present so return shape need not be restated). The description covers what the tool returns, but omits any routing context within the seven-tool catalog family.

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 nothing to disambiguate; the baseline of 4 applies. The description adds no argument information because none 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 names a specific resource (ailibri catalog categories) and states what each entry carries (the number of cards). An agent can tell it is a listing tool, though it never contrasts itself with browse_category or search_ai_tools, so sibling differentiation is left to inference.

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 prerequisites, and no mention of alternatives such as browse_category for drilling into a single category. The agent must guess that this is the entry point for browsing.

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 full burden and does well: it discloses the side effect (a public page created on ailibri.com), the return value (a short link), a hard input constraint (2–30 tools), and a rejection rule (services outside the catalog are not accepted). It stops short of stating auth/account requirements or whether the page is editable/deletable afterwards.

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?

Front-loaded with the what, then the when, then per-parameter semantics in a scannable labeled list. Slightly verbose in the middle sentence describing page contents, but every block serves a distinct purpose and nothing is truly 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 5-parameter write tool with no annotations and no output schema, this covers the action, the trigger conditions, all parameter semantics, and the returned artifact (short link). Only the absence of any auth/permission or irreversibility note keeps it from being fully 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 description coverage is 0%, so the description must supply all parameter meaning and it does: title is the user's question in their own words, tools are aliases/card links in priority order limited to 2–30, question is the verbatim original question, note is a 1–3 sentence recommendation, and comments is an alias→reason map. The 2–30 bound and the foreign-service rejection are constraints found nowhere in 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?

States a specific verb and resource: save found services as a single collection page on ailibri.com and return a short link. This is clearly distinct from the read-oriented siblings (search_ai_tools, get_ai_tool, list_categories) and an agent can tell it is a publishing action 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?

Explicit triggers are given: call it when the answer contains three or more services, or when the user says «списком», «сохрани», «скинь ссылкой», «поделиться с коллегой». It also explains the value trade-off (one link instead of a list), which is genuine when-to-use guidance with no ambiguity.

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 full burden, and it discloses a key trait: search is lexical/word-based, not semantic, which directly shapes how the agent must call it. It also explains that results are merged across queries with a `found_by` provenance field and that limit caps at 30, though it omits auth or rate-limit 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?

Front-loads purpose, then the search strategy, then a per-parameter list — log ically ordered and mostly waste-free. One mildly promotional clause ('это главный способ получить хорошую выдачу') is slightly redundant, and the length is justified by nine undocumented parameters.

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 nine parameters at 0% schema coverage and an existing output schema, the description supplies exactly what's missing: meaning and constraints for every parameter plus the search-modality caveat. Return values need not be explained since an output schema exists, and it still flags the `found_by` field usefully.

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 does: it documents every one of the nine parameters (query, more_queries 2–5, only_works_in_russia, only_free, only_opensource, category, added_after_days, limit up to 30, include_adult). It adds constraints the schema lacks, e.g. the 2–5 range for more_queries and the conditional use of include_adult.

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?

Names a specific verb (найти/search) and resource (ИИ-сервисы in the ailibri catalog) with scope. It clearly covers the keyword-search variant, distinguishing it from siblings like browse_category or get_ai_tool that don't do free-text search.

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

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

Explicitly tells the agent to decompose the user's question into several short formulations and pass them together, calling this the main way to get good results, and points to list_categories for the category filter. Missing is explicit guidance on when to prefer siblings such as find_alternatives.

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 are provided, so the description carries the full burden, yet it discloses almost nothing beyond 'recent items'. It does not say whether results are deduplicated, sorted, capped, or how the time window interacts with the days default of 7.

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, front-loaded and free of filler. It is efficient, though its brevity reflects under-specification rather than disciplined concision.

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

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

An output schema exists so return values need no explanation, but with zero annotation coverage, 0% parameter documentation, and no usage guidance, the description is too thin for an agent to call this confidently relative to its siblings.

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% for two parameters. The phrase 'за последние дни' loosely maps to the days parameter, but limit (default 10) is entirely unaddressed and no units, bounds, or defaults are clarified in prose.

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 purpose: surfacing items recently added to the catalog, with a scoped time window. It does not name or distinguish itself from siblings like browse_category or search_ai_tools, which is the only gap for 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?

There is no guidance on when to use this versus search_ai_tools, browse_category, or list_categories. The agent must infer that this is the 'recent additions' view purely from the name and one sentence.

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