Get delivery status

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a read-only operation. The description adds value beyond annotations by specifying that it returns a plain-word explanation of the status and includes details like costs and operator info. This helps set expectations about the response content without contradicting the 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 two sentences, front-loaded with the core purpose and then the usage guidance. Every sentence earns its place: the first defines the operation and what it returns, the second gives explicit context for when to use it. There is no filler or redundancy, making it highly efficient.

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 tool with a single parameter and no output schema, the description is quite complete. It enumerates the types of information returned (status, operator info, phone, scheduled time, costs) and notes that the status is explained in plain words. While it doesn't provide a formal structure of the response, that's not strictly necessary given the description's clarity. The usage context is also well specified, covering common scenarios.

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 input schema covers 100% of the parameter, and the parameter 'id' is already described as 'Delivery ID from the send_message or send_file response.' The description does not add any additional semantic detail about the parameter, so it fully relies on the schema. Per the guidelines, baseline 3 is appropriate since schema coverage is high and no extra clarification is needed.

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 (Get), a clear resource (delivery status of a specific message by ID), and lists the key details returned (status, operator info, phone, scheduled time, costs). It also mentions the status is explained in plain words, which clarifies its output. This clearly distinguishes it from sibling tools like get_balance or get_account, which are about account-level data.

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 explicitly states when to use this tool: 'Use it after send_message or send_file when the user asks whether a message was delivered or read, or why it failed.' It also implies the prerequisite of having a delivery ID from a prior send. While it doesn't explicitly mention alternatives or when not to use it, the given context is sufficient for an agent to select it appropriately among the sibling tools.

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