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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds context beyond that: it explains that no organization ID is required because the authenticated connection determines it, and it discloses the permission requirement and the recommended action if access is denied. This is useful behavioral context not covered by 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?

Three sentences, each with a distinct purpose: the first lists what is returned, the second explains the use and the lack of a parameter, and the third covers the permission and alternative tool. There is no redundancy or filler—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?

Given that the tool has no parameters and there is an output schema (so return format is documented), the description covers purpose, usage, permission, and distinguishes it from get_usage. Nothing critical for calling this tool correctly is missing, making it complete.

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?

There are zero parameters, so the schema is vacuous. The description explicitly states that no organization ID is needed and that the connection determines the target, which adds meaning beyond the empty schema. Since the baseline for 0 params is 4 and the description adds clarity, it earns a 4.

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') and resource ('the connected ErzyCall organization'), and enumerates the exact fields returned (ID, name, description, contact email/phone, profile timestamps). It also clarifies the tool's role—identifying which organization the connection can access—and explicitly differentiates from get_usage by pointing to it for plan/balance info.

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?

It provides a clear use case ('Use this to identify which organization this connection can access'), names an alternative for a specific need ('For plan and balance information, use get_usage'), and warns that it requires organization:read permission, with guidance to reconnect and authorize if access is denied. This is explicit when-to-use and when-not-to-use guidance.

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