Invoke a raw MTProto method

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

Beyond the annotations (openWorldHint, destructiveHint), the description discloses that string values for peer-like fields are auto-resolved to InputPeer/InputUser, which is critical for invocation. It also reiterates the lack of safety checks, adding context that annotations only flag indirectly. It doesn't cover all potential behaviors (e.g., error handling), but the key risks are addressed.

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?

The description is three sentences, each serving a distinct purpose: stating the core function with examples, explaining a key behavioral transformation, and providing usage guidance. No redundant or filler content, well-paced and 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?

For a raw fallback tool with open-world semantics and no output schema, the description covers the essential operational knowledge: purpose, usage constraints, security caveat, and parameter transformation. It omits details like return format or error behavior, but given the tool's general-purpose nature, it is sufficiently complete for an agent to select and invoke correctly in most cases.

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 67%, and the description adds significant value by explaining the auto-resolution rule for the `params` object and giving method-name examples. It clarifies how to use the two main parameters, though `accountId` remains undocumented. The description goes beyond the schema's minimal property descriptions.

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 clearly states the tool calls any Telegram API method by qualified name, with concrete examples (e.g., messages.SendMessage). It explicitly distinguishes itself from dedicated siblings by saying 'Use this only when no dedicated tool fits', making its purpose and scope 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?

The description gives explicit usage guidance: use only when no dedicated tool fits. It also warns about the huge API surface and absence of per-method safety checks, helping the agent avoid misuse in favor of safer dedicated tools.

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