get_message_context

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

No annotations and no output schema, so the description carries the full burden. It does convey the core behavior — returning messages before and after a target message with defaults of 5 each — but says nothing about ordering, whether media is included, permission/auth requirements, or what happens with an invalid or deleted message_id.

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?

Short and front-loaded: a single summary sentence followed by a compact Args block. No padding, though the defaults in the Args section duplicate what the schema already declares.

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 simple read-only retrieval tool this covers the essentials, but with no annotations and no output schema the definition should say more about the returned shape (e.g., ordering, inclusion of target message, media handling) and edge cases like an unknown message_id.

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 0%, so the description is the only source of parameter meaning, and it documents all three params: message_id as the target and before/after as counts of surrounding messages. It effectively compensates for the empty schema, though it repeats the defaults already declared in the schema and omits any bounds or limits.

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 ('Get context around a specific WhatsApp message'), which is clearly distinct from siblings like list_messages or get_last_interaction. It doesn't explicitly name an alternative, but the resource is specific enough for an agent to place it in the chat-reading family.

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 use case (fetch surrounding messages around a known message_id) is implied by the purpose and the before/after parameters, but there is no explicit when/when-not guidance and no mention of alternatives such as list_messages or get_last_interaction. The agent must infer when this is preferable.

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