getChat

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

With no annotations provided, the description carries the full disclosure burden. It discloses the success return type (ChatFullInfo) and implies read-only behavior via the verb 'Get', but does not disclose failure modes, permission requirements, or rate-limit behavior. This is adequate for a simple read tool but relies on inference rather than explicit disclosure.

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 totaling roughly 17 words with zero waste. The primary purpose is front-loaded in the first sentence and the return type in the second, and it does not repeat schema content.

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 tool with no output schema, the description plus schema is nearly sufficient: chat_id is documented and the return type is named in prose. Missing are failure-mode notes and steering away from confusing siblings, but an agent has everything needed to make a correct call.

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 100%: chat_id is fully documented in the schema, including the integer/string union and the @channelusername format for supergroups and channels. The tool description adds nothing about the parameter, which matches the baseline 3 for high schema coverage.

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 ('Get') and resource ('the chat'), and names the return type (ChatFullInfo object), which differentiates it from sibling sub-resource getters like getChatAdministrators, getChatMember, and getChatMemberCount. However, it does not explicitly name any sibling it is not, so differentiation is implicit rather than stated, which keeps it from 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?

No explicit when-to-use guidance, exclusions, or alternative tool names are provided. The phrase 'up to date information' only implicitly suggests using this when the full current chat state is needed rather than a sub-resource. Given roughly 130 siblings including several confusable getChat* variants, explicit routing would add significant value.

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