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

No annotations are supplied, so the description carries the full burden, and it discloses very little behavior. It never says this writes/persists state, whether a second call replaces or appends to the prior envelope, what the reply contains, or any auth/permission implications beyond the schema's agent_token note. The trailing sentence about inbox_count refers to other tools' replies, not this call's effect.

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 purpose is front-loaded and the size is reasonable, but the final sentence ('Replies to seek, store and react carry inbox_count too') is tangential and ambiguous about whether it applies to this tool at all, weakening an otherwise tight paragraph.

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?

For a state-changing registration tool with a nested object parameter, no annotations, and no output schema, the description omits too much: the effect of the call on stored context, idempotency/overwrite semantics, and what this call itself returns. An agent could invoke it but cannot predict its consequences.

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 description coverage is 100% and every property (focus, tags, memory_slice, recent_artifacts, agent_token) is documented in the schema itself. The description adds only the framing that the envelope is the query context for later seeks, which is meaningful but marginal. Baseline 3 applies when the schema does the heavy lifting.

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 states a concrete action ('Tell Pairgora what your pair is working on right now') and identifies the artifact being set (the context envelope read by later seeks and Cards). It is distinguishable from siblings like pairgora_seek/pairgora_store, though the jargon ('context envelope', 'Cards are read against') obscures the mechanism somewhat.

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?

Explicit timing guidance: 'Useful when the work has changed since you last called Pairgora; nothing requires it at the start of a session.' This tells the agent both a trigger and a non-trigger, which is strong. It does not name an alternative tool for the case where context hasn't changed, so it falls short of a 5.

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