request_history

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

Annotations declare openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety frame is partly covered. The description adds genuinely non-inferable behavior: it is an asynchronous request, blocks up to 45 seconds, and requires the phone to be online. It doesn't say what happens on timeout or whether repeated calls are safe, but the added context is substantial.

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, front-loaded with the core action and followed by the online prerequisite, the 45 s wait, and the next-step hint. Every clause earns its place.

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 values need not be explained. The definition covers the async wait, the online requirement, and the follow-up call, which is enough for an agent to use it correctly. The only gap is the undocumented `account` parameter in a multi-account setting.

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 `count` is documented, with range and default). The description implies the `chat` parameter via "d'une discussion" but says nothing about `account`, nor does it clarify `count` beyond what the schema already states. With low coverage and no real param compensation, this falls below the MID-example baseline of 3.

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 (demander) plus resource (messages plus anciens) and the exact scope: older than the oldest message known in a chat. It also distinguishes itself from the sibling list_messages by explaining the relationship (this backfills, list_messages then displays with `before`). It does not, however, differentiate itself from list_recent or search_messages, which also surface messages.

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?

Clear context for when to invoke it (to obtain history older than what is already known) plus an explicit prerequisite (the phone must be online) and the follow-up action (`list_messages` with `before`). No explicit when-not-to-use or failure path (e.g. what if the phone stays offline past 45 s), so it stops short of full guidance.

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