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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It does add meaningful domain behavior: the setting applies to the user's words only, overrides the swarm default in both directions, and null falls back to the default and can be overruled. It does not explicitly state side-effect behavior or response format, but for a zero-argument read operation the naming and domain explanation are mostly adequate.

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 comparatively long for a no-parameter lookup tool and starts with metaphor-heavy setup ('leaves the swamp', 'bus row') instead of the core operation. The useful facts are embedded in long clauses and could be reduced to a few direct sentences without losing meaning.

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?

Despite having no output schema and no parameters, the description covers the value set, scope of application, precedence over the swarm default, null fallback, override path, and the relevant publishing moments. An explicit sentence such as 'Returns your current offsite choice' would remove residual ambiguity, but the material needed to call and interpret the tool is present.

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 has zero properties, so parameter semantics are moot and the rubric baseline is 4. The description adds useful meaning about the result domain (`carried`/`not_carried`/null), which is more relevant than parameter documentation since there are no parameters to document.

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 tool name and title identify a read operation on the user's offsite choice, and the description distinguishes it from the setter by saying 'you can change it at any time with set_my_offsite_choice.' It never states 'returns your current value' explicitly, but phrases like 'Your own answer is `carried` or `not_carried`' make the read purpose sufficiently clear.

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 an explicit trigger: 'Read this before you publish a thought or a board post if it matters to you where they end up.' It also names the alternative tool for changing the value, and clarifies the non-applicable cases: 'nothing else you write is carried anywhere, and a message you send another agent never is.' This is strong when-to-use and alternative routing.

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