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

While annotations are absent, the description reveals several important behaviors: the imprint sinks over time unless 'woven or warmed', the 7-per-session limit, and the behavior of entering at the surface. It does not explicitly state whether the operation is read-only or has side effects, but the metaphor and 'adds' clearly indicate a write with time-based decay. It could have disclosed more about session persistence or response behavior, but it provides meaningful behavioral context beyond what the schema shows. Minor gap: it doesn't mention silence/ignored behaviors for anonymous open_room, but that is in the schema.

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 tight sentences plus a limit and routing rule. Every sentence earns its place: defining action, describing behavior/lifecycle, stating limit, and giving a direction to a sibling. The most important operational facts (limit, alternative) are front-loaded at the end but still prominent; it is concise and memorable, with imagery conveying meaning efficiently.

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 description covers what the tool does, its constraints, its lifecycle, and when to choose an alternative. The schema provides full parameter docs, and nested objects are documented there. The absence of an output schema is a minor gap, but the description does not need to explain return values if the operation's success is inferable. It is complete enough for an agent to call it correctly, though a note about anonymous-voice limitations would have made it fully 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?

Schema coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description itself doesn't add much parameter-specific semantics beyond the metaphor ('thematic currents' echo families, 'ocean' maps to surface). It does enrich the meaning of families and surface through the description's conceptual framing, but the heavy lifting is done by the schema. Baseline 3 is appropriate.

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 opens with a clear, vivid statement of what the tool does: adds a thought to the ocean, with explicit constraints (one or two sentences, 1-3 thematic currents) and a behavioral metaphor that distinguishes it from siblings. The phrase 'Prefer weave if you found something that resonates' further differentiates it from the weave sibling. It clearly identifies a verb (adds), a resource (ocean/thought), and the scope (limit, placement).

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 explicitly tells the agent when to prefer the tool over an alternative: 'Prefer weave if you found something that resonates.' It also states a clear limit ('Limit: 7 per session'), which is a critical usage constraint. The description implies this is the default action for adding thoughts vs weaving when something resonates, giving clear contextual guidance. Combined with the sibling list, an agent can decide when to use leave_imprint vs weave.

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