send_message

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

With no annotations provided, the description carries the full burden of disclosing behavior. 'Reply in an existing conversation' implies a mutating action, but the description does not state consequences, prerequisites (e.g., whether an existing conversation must be fetched first), what happens if the thread doesn't exist, or any error behavior. The term 'reply' vaguely hints at a write operation, but this is under-specified for a mutation tool. No contradiction with annotations exists only because there are no annotations.

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?

The description is a single front-loaded sentence with no wasted words, which is efficient. However, its terseness contributes to the cryptic nature of 'matched by recruiter/company name' — it is concise but at the expense of clarity. It earns credit for being short and front-loaded, but the phrasing is dense and slightly confusing, warranting a middle score.

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 side-effecting tool with no annotations, no output schema, and 0% parameter coverage, the description is under-specified. An agent cannot determine the exact expectation for thread_query (name format), the role of text, or what distinguishes a successful send from a failure. The presence of sibling tools like get_conversation suggests context, but the description itself leaves significant gaps for this mutation operation.

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 a low 0%, so the description must compensate. It partially does by clarifying that thread_query matches against 'recruiter/company name,' adding meaning beyond the literal 'Thread Query' label. However, it does not clarify whether thread_query is a full name, a partial query, or which field takes precedence, and 'text' is entirely undocumented. The description adds some value for thread_query but leaves text and the exact matching semantics ambiguous.

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 uses a specific verb ('reply') and identifies the resource ('an existing conversation'), with a distinguishing scoping detail ('matched by recruiter/company name'). It implies this is not for starting new conversations, partially differentiating it from a hypothetical 'new message' tool. However, it could more explicitly state this is a message-sending action, and the phrase 'matched by recruiter/company name' is slightly ambiguous without context, so it doesn't quite merit 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?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it name any sibling tool as an alternative for different scenarios. Given the sibling list includes get_conversation and get_inbox, the distinction from those is left entirely to inference. There is no condition or exclusion stated, so an agent must infer all usage context from the surrounding tool family alone.

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