reach_getConnectedSendingDomainV1

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

No annotations are present, so the description carries the full burden. It discloses the null-shape behavior for profiles without a connected domain and clarifies the operation is a read-only precondition check. It stops short of discussing auth or errors, but the key behavioral edge case is well covered.

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?

Four dense sentences with no filler. The core purpose is first, followed by practical usage context, a null-behavior caveat, and a pointer to the sibling endpoint. Every sentence earns its place.

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?

The description fully explains what the tool returns, when to call it, how it behaves in the edge case, and which sibling to use for related but different data. For a single-parameter read operation, no critical information is missing.

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 100% and the single parameter profileUuid is present in the schema. The description does not add much beyond the schema, but it also does not need to, since the parameter meaning is straightforward and documented.

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?

States a specific verb and resource: getting the sending domain connected to a profile, plus the verification status and suspended sender addresses. This clearly distinguishes the tool from the DNS-status sibling by naming the exact data it returns.

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?

Explicitly says when to use it: as the cheapest precondition check before building a campaign. It also names the alternative endpoint to use when individual DNS records are needed, so the agent receives direct routing guidance.

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