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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the baseline is covered. The description adds useful behavioral context by listing the exact fields returned and clarifying that results identify company scope for later reads, though it does not discuss authentication requirements beyond 'authenticated account' or any limits.

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?

A single dense but well-structured sentence that front-loads the action and purpose. Every element, including the returned fields and downstream use, 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?

With no input parameters and no output schema, the description carries the burden of explaining return values, which it does by listing the key fields. It does not describe ordering, pagination (likely irrelevant with zero parameters), or how many companies may be returned, but is otherwise complete for a simple listing tool.

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?

This tool has zero parameters, so parameter semantics are not a concern. The baseline for zero-parameter tools is 4, and there is no additional parameter meaning for the description to convey.

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 (list Switchbooks companies) and enumerates returned fields (IDs, names, legal entity names, descriptions, active company). It distinguishes itself from mutation-oriented siblings like set_company by identifying available company scope, though it does not explicitly name alternatives.

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 gives clear context for use: call this to discover the company scope for subsequent bookkeeping reads. It does not explicitly state when not to use it or contrast it with set_company or get_switchbooks_info, leaving some inference to the agent.

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