search

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

No annotations are provided, so the description carries the full disclosure burden. It usefully characterizes mode behavior (exact words vs meaning-based vs rank fusion), but says nothing about result caps, pagination, ordering, or required permissions for reading a community's messages.

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 summary sentence followed by tight, scannable lines mapping parameters to meaning, with the recommended mode flagged inline. No filler and the purpose is front-loaded.

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 fields need not be described, and the mode/filter semantics are covered. What remains thin is the undocumented 'limit' parameter and any sense of result volume or pagination, which matters for a search endpoint.

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 is the only source of parameter meaning, and it does good work: it enumerates the three mode values, explains chat_id filtering, and gives an ISO format example for date_from/date_to. It leaves 'limit' and 'query' undocumented, which is a partial gap for a 6-parameter tool.

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: 'Search Telegram community messages,' which immediately tells an agent what the tool returns. It does not, however, distinguish itself from siblings like list_chats or get_context, so an agent must infer the boundary on its own.

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 explains the three search modes and explicitly marks hybrid as 'recommended,' giving clear guidance for the most important decision. It stops short of saying when to prefer this tool over siblings or when a mode is inappropriate (e.g. short keyword-only lookups), so no exclusions are covered.

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