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

With no annotations, the description carries the full burden, and it does disclose the single most important behavioral fact: calling without `_project=` leaves the caller out of any project, and the tool has no side effects. What it omits is the confirmation that calling it with no arguments is harmless and returns nothing meaningful, and it says nothing about the `_org` parameter's behavior. For a no-op tool this is decent but not complete disclosure.

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?

It is a single short sentence, which suits a trivial tool, but the structure front-loads jargon ("No-op hint", "ADR 0038") rather than the actionable fact. The ADR citation and the discussion of a nonexistent `_project` parameter do not earn their place for an agent deciding whether to call the tool.

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 tool is trivial (zero required params, no output schema), so expectations are low, but the description still fails to state plainly that the tool is a no-op and should generally be skipped. It also leaves the sole parameter `_org` unexplained and gives no routing among the clear_use sibling tools.

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 schema has one optional parameter, `_org`, at 0% description coverage, and the description never mentions it. The parenthetical references `_project=`, a parameter that does not even exist in this tool's schema, which is confusing rather than clarifying. No meaning is added beyond the bare schema.

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 labels the tool a "No-op hint" and ties it to ADR 0038, which does hint that the tool performs no action because there is no session state to clear. However, it never plainly states "this tool does nothing and has no effect," leaving an agent to infer the purpose from a parenthetical about architecture. The name oto_clear_project suggests a state-clearing action that the description implicitly denies, without resolving that tension 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?

There is no guidance on when to call this versus siblings like oto_clear_org, oto_clear_group, oto_use_project, or oto_use_org, which clearly form a project/org/group scoping family. The description also never says whether the agent should call it at all — a critical guideline when the tool is a no-op. Usage must be inferred entirely from the "no-op" label.

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