sendMessage

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 does disclose the return value ('Returns the sent Message on success'), which is useful given the absent output schema, but it omits side effects (the message is delivered to real users and cannot be retracted), permission prerequisites (bot must be a chat member), and error/failure behavior. For a state-changing send operation, this is a significant 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?

Three short sentences in roughly 20 words: core action first, then capabilities, then return value. Every sentence earns its place, there is no filler, and it avoids repeating the 15 parameters already documented in the schema.

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 15-parameter tool with no annotations and no output schema, the description covers purpose and return value but leaves sibling differentiation, failure behavior, and prerequisites unaddressed. The rich schema covers parameter semantics, but the operational context an agent needs to choose and invoke this reliably among roughly 250 siblings is incomplete.

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% with detailed per-parameter descriptions, so the baseline is 3. The description adds only a light grouping ('Supports formatting, reply markup, and various message options'), which maps loosely to parse_mode/entities, reply_markup, and the option flags, but does not add meaning beyond what the input schema already provides.

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: 'Send text messages to a chat,' which differentiates it from the many media-sending siblings (sendPhoto, sendAudio, sendDocument) by the word 'text.' The mention of formatting, reply markup, and the returned Message adds specificity, though it doesn't explicitly delineate from near-neighbors like sendMessageDraft or editMessageText.

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 when-to-use or when-not-to-use guidance is provided. With over a dozen send* siblings plus editMessageText, copyMessage, and forwardMessage in the tool list, an agent gets no explicit signal about which alternative fits other content types or the message-editing case, and must infer everything from the word 'text.'

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