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

Goes beyond the annotations (idempotent, non-destructive, non-read-only) by disclosing server-side authorization: an organization the person does not belong to is refused, and the choice is re-validated on every subsequent call. That persistent-session and validation behavior is exactly the kind of context annotations cannot express.

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?

Two sentences, both load-bearing, with the effect (what later tools act for) front-loaded and the failure mode second. No filler or restatement of the title.

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 output schema and one undocumented parameter, the description should say what a successful selection returns and how long it persists (per-session vs. per-conversation). It covers the authorization rule but leaves those operational details 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 0% — organization_id has no description, only a uuid format and pattern. The description partially compensates by implying the ID must be an organization the person belongs to, but it does not say where to source a valid ID or whether an alternative like the zero-UUID sentinel is meaningful.

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 (choose) and resource (organization) plus its downstream effect: it sets the subject that later merchant tools act for. That distinguishes it from list_subjects (discovery) well enough to route correctly, though it never names that sibling explicitly.

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?

"later merchant tools act for" implies this is a prerequisite step before merchant calls, but the timing is left to inference. There is no explicit instruction on how or when to obtain a valid organization_id (e.g. via list_subjects) and no stated when-not case.

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