get_chat_history

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose two non-obvious traits: data comes from a buffer and the result count is capped by buffer capacity. It omits ordering, whether the buffer is live/truncated in normal operation, and any auth requirements, so the disclosure is partial rather than complete.

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 clauses, front-loaded with the core action, and no filler. It is efficient, though the buffer caveat could be tied more tightly to the limit parameter rather than standing as a trailing sentence.

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 formatting is not required in the description. For a simple two-parameter read tool this is nearly adequate, but the missing differentiation from get_recent_messages and unexplained limit parameter leave gaps an agent must guess at.

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 0%, so the description must compensate. It clarifies that chat_name is mandatory (the schema only marks requiredness without semantics) and hints that returned volume is bounded, which loosely relates to limit, but it never explains what the limit parameter does or its default.

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 states a specific verb and resource (read the most recent messages of a designated chat), so the agent knows exactly what the tool returns. However, it never distinguishes itself from the sibling get_recent_messages, which appears to cover overlapping ground, leaving the selection ambiguous.

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 states a prerequisite — the chat name must be explicitly supplied — which is useful before calling. But there is no guidance on when to prefer this over get_recent_messages or how it relates to get_chat_info, so the usage context is only implied.

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