Catalogue App

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

Annotations declare readOnlyHint=true, which could look surprising for a tool named create_bot, but the description resolves it precisely: the tool returns a link, and creation only happens when the user opens Telegram and confirms. It adds real context beyond the annotations — no @BotFather or token needed, the bot is hosted by @catalogue_app, it stays editable in the node editor, and it is free.

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

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

Three tight sentences, front-loaded with the outcome (a one-tap creation link) before the how-to. The one-tap/no-BotFather framing earns its space as genuine differentiation, though the trailing 'Free.' fragment is the weakest element.

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-required-parameter tool with no output schema, the description supplies everything an agent needs: what is returned (a link), who acts on it (the user, in Telegram), what happens afterward (bot goes live, hosted, editable), and the absence of setup requirements. Nothing material 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?

With 67% schema coverage the schema already documents template and description; the description adds the precedence rule (a template takes priority over the free-text description) and points to list_bot_templates as the slug source. The language parameter is never mentioned, though its en/ru enum is self-explanatory.

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 — 'Get a link that creates the user's own Telegram bot' — and immediately differentiates itself from sibling list_bot_templates by naming it as the source of template slugs. An agent can tell this apart from create_pack or the search_* tools without opening any 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?

Gives two explicit invocation paths — pass a template slug from list_bot_templates, or describe the bot in plain words — and implicitly routes agents to list_bot_templates first when a slug is needed. It does not state a when-not-to-use case (e.g. the user already has a bot), so it falls short of full alternative routing.

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 adds the critical behavior the agent could not get from annotations: the tool does not create the pack itself, it returns a t.me link that opens the studio with the request pre-filled. This reconciles well with readOnlyHint=true and idempotentHint=false (fresh link each call), so nothing is contradicted. It stops short of saying whether the link expires or requires Telegram auth.

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, front-loaded with the actionable outcome (getting a link) followed by what the studio does and what is returned. The 'free Catalogue App' branding is slightly promotional but each sentence carries real 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-parameter, read-only link generator with no output schema, the description covers the input intent, the fact that no pack is actually created, and the shape of the return value (t.me link). An agent has enough to call it correctly and describe the result to a user.

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?

At 50% schema coverage, 'custom emoji or sticker pack' loosely maps to the kind enum and 'assembled from the library by theme' echoes the prompt field, but the schema already defines both. The description adds intent rather than new syntax, options, or constraints for either 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 states a specific verb and outcome — 'Get a link to the free Catalogue App pack studio' — and clarifies that photos, videos or GIFs become an emoji or sticker pack. This distinguishes it from the search_packs sibling by outcome, though it never names an alternative tool 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: the agent can infer this is the entry point for building a pack from the user's own media or by theme. There is no explicit when-to-use/when-not guidance, no mention of search_packs for existing packs, and no prerequisites such as the user needing a Telegram account.

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 covered. The description adds real value by explaining what each entry actually is ('a ready bot graph with a one-click creation link'), but says nothing about result size, pagination, or whether the links are the only way to instantiate a template.

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 tight sentences with the core purpose front-loaded and examples parenthesized rather than enumerated in prose. Every clause carries information; only the example list could be trimmed.

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, zero-required-parameter, read-only listing tool with no output schema, the description covers what is returned well enough: named template categories presented as ready bot graphs with creation links. The unaddressed language parameter and lack of any result-size hint are the only gaps.

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% and the description never mentions the single 'language' parameter (en/ru). It is unclear whether the parameter localizes template names, descriptions, or the creation links, so the description does not compensate for the schema gap.

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 gives a specific verb+resource ('List Catalogue App bot templates') and enumerates concrete template kinds (support, feedback, shop, paid channel, captcha), which clearly separates it from siblings like search_apps or create_bot. It stops short of explicitly naming an alternative, but the scope 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?

Usage is only implied: the mention of a 'one-click creation link' suggests this is the discovery step before creating a bot, but the description never says when to call this versus search_apps/search_packs or create_bot. An agent can infer intent but gets no explicit routing guidance or exclusions.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description only needs to add context. It adds the result shape (name, category, one-line description, links) and usefully flags that monthly users are reported only 'where measured', i.e. the field is optional. It says nothing about result caps, empty-result behavior, or how the fixed catalogue is kept current.

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 purpose and searchable fields front-loaded and the return shape following. Every clause carries distinct 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 read-only two-parameter search with no output schema, the description adequately covers what goes in and what comes back, including the caveat that user counts are not always available. The remaining gap is the undocumented 'limit' parameter and the absence of any note on truncation or total match counts.

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%: 'query' is documented in the schema and the description merely restates the same name/@username/topic forms, while 'limit' (default 10, max 30) is documented nowhere at all. With half the parameters unexplained, the description should have clarified paging/truncation semantics but does not.

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 verb ('Search') and a precisely bounded corpus ('Catalogue App directory of Telegram mini apps, bots and TON services'), which lets an agent distinguish it from search_channels and search_packs without opening a schema. It stops short of a 5 because it never explicitly acknowledges those siblings or states the exclusion.

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: the accepted query forms ('by name, @username or topic') suggest how to call it, but there is no statement of when to prefer this over search_channels/search_packs, no prerequisites, and no guidance on broadening or narrowing a query that returns nothing.

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, non-destructive and closed-world behavior. The description adds real context beyond that: the corpus is public channels tracked by Catalogue App with 1.5M+ entries, and the result fields are enumerated. It omits pagination and how the 15/50 limit cap behaves, which keeps it from a 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?

Three short sentences, front-loaded with scope and size of corpus, then filtering, then return fields. No filler or redundant restatement of the name.

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 lists return fields (@username, title, kind, subscriber count, links), so an agent knows what comes back. The gap is result-set behavior: default 15 / max 50 limit semantics and whether results are ranked or truncated are unaddressed.

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 50%, so the schema documents query and kind but leaves min_subscribers and limit bare. The description's 'filter by kind and size' maps loosely onto kind and min_subscribers, giving a hint about the size filter, but it never explains limit or the enum value 'room'. Baseline 3 given partial 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?

Specific verb plus resource with scope: 'Search 1.5M+ public Telegram channels, group chats and bots tracked by Catalogue App.' The resource is clearly distinct from the sibling search_apps and search_packs without needing to open any 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?

The description implies usage context ('Filter by kind and size') but never states when to prefer this tool over siblings like search_packs or search_apps, nor any exclusions such as private or untracked chats. The purpose makes the intent inferable, but no explicit when/when-not guidance is given.

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 value beyond that by naming the return fields (pack title, short name, add link format, catalogue page) — useful since there is no output schema. It stops short of describing result ordering or truncation behavior at the limit cap.

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 tight sentences with zero filler: capability and scope first, return shape second. Every clause carries information an 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?

For a three-parameter read-only search with no output schema, the description covers purpose and return contents well. The remaining gap is behavioral rather than descriptive: what limit does and whether results are ranked or paginated.

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 only 33% — only query is documented. The description partly compensates by implying the kind dimension ("emoji and sticker packs") and by broadening query semantics to theme, title, emoji or pack name. It says nothing about limit or its default of 10, so the compensation is partial.

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 ("Search") and resource ("Catalogue App library of Telegram custom emoji and sticker packs") plus the searchable dimensions (theme, title, emoji, pack name). That is enough to distinguish it from siblings like search_apps or search_channels, which target different catalogues.

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 search intent is implied and reasonably clear, but the description never states when to use this rather than create_pack (the sibling that adds packs) or how to choose between kind=emoji vs kind=sticker. No exclusions or alternative routing are given.

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 establish that this is a safe, idempotent, closed-world read, so the description's added value is limited to noting that the content is 'practical, current' and includes links to official docs — genuinely useful signals about currency and that URLs come back. It does not say whether this is a static snapshot or a live fetch, nor how the notes are structured or how long they are, which matters since 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 front-loaded sentence with a topic list that mirrors the enum and no filler. Slightly list-heavy in structure, but every element maps to something 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?

For a one-parameter, read-only reference tool with no output schema, the description covers what content exists and that official doc links are included, which is close to sufficient. Only the snapshot-vs-live nature and rough response shape are left unstated.

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 carries the burden, and it largely does: it glosses the enum values in plain terms (managed bots = one-click bots, packs = custom emoji and sticker packs, stars = payments, webhooks and limits). It does not gloss the 'overview' value or the default behavior, which is the remaining gap.

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 knowledge base of notes on building for Telegram) and enumerates the covered subject areas, which clearly separates it from action siblings like create_bot, create_pack, and search_packs. It never uses an explicit retrieval verb ('returns', 'look up'), so the agent must infer from the title that this is a documentation lookup rather than an 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?

Usage is only implied: the list of topics hints at when the tool is worth consulting (before building a Mini App, handling Stars payments, etc.), but there is no explicit 'use this when' clause, no statement that it should be called before create_bot, and no guidance on when not to bother. The agent must infer the routing from the sibling names alone.

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