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

The annotations lack detailed hints (no readOnlyHint, no idempotentHint), but the description adds valuable behavioral context: it mentions the tool queues a run without waiting, returns immediately, and provides a chat_id for continuation. It also implies that the tool is not read-only (since it queues a run) and not idempotent (though the idempotency_key parameter suggests retry support). This goes beyond the annotations and helps the agent understand the asynchronous nature.

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 compact and well-structured, with the core purpose in the first sentence, followed by key behavioral notes and pointers to related tools. Every sentence carries meaning, and the most critical info (non-waiting, immediate return, chat_id) is front-loaded. No fluff.

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?

Given the complexity (3 params, output schema present, openWorld annotation), the description is mostly complete. It covers the key aspect of asynchronous behavior and how to proceed. It could mention the need for authentication or that it creates a new chat, but these may be implicit or covered by other tools. The output schema likely documents the return structure, so description need not repeat it. Slight gaps in explicit alternative routing, but overall adequate.

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?

The schema already provides detailed descriptions for all three parameters, with 100% coverage. The description does not add significant new information about the parameters beyond what the schema gives. The mention of 'chat_id' and 'continue with send_message' is about the output, not the parameters, so the contribution is minimal. Baseline of 3 is appropriate.

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 clearly states the tool's purpose: 'Open a chat with the Crevio agent and queue a run, without waiting.' It identifies the specific resource (chat) and the action (starting a chat and queueing a run). It also differentiates from siblings by mentioning the immediate return and naming send_message, wait_for_run, and get_run as related tools, though it doesn't explicitly compare to siblings like ask_crevio or api_execute.

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 good usage context by explaining that it runs without waiting and that the returned chat_id is used for continuing with send_message. It also suggests following the run with wait_for_run or get_run. However, it does not explicitly state when NOT to use this tool or name alternatives like ask_crevio, which is a minor gap.

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