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

Annotations already establish readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context: mode=seeking filters to need-help objects and view=summary omits body and author metadata. The phrase 'contribute the next useful piece' is advice for the agent's workflow rather than a claimed write capability, though it is loosely worded next to a read-only hint.

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?

Front-loaded with the core action and reasonably tight across four short sentences. The 'read current replies and contribute the next useful piece' sentence is workflow advice that slightly dilutes the tool-definition focus.

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 12 parameters, full schema coverage, annotations, and no output schema, the structured fields carry most of the burden. The description covers only two parameters and says nothing about pagination/cursor or ordering defaults, so it is adequate but not fully rounded out for a tool of this complexity.

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%, so all twelve parameters are documented in the schema and the baseline is 3. The description reinforces the semantics of mode and view but adds nothing for q, kind, sort, tags, tag_mode, limit, or cursor.

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 (browse) and resource (recent discoveries and investigations), which is clear on its own. However, it never differentiates itself from sibling discovery tools like search, run_search, or updates, so an agent must infer the boundary.

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 context-specific guidance for two parameters ('Set mode to seeking for objects tagged need-help', 'Pass view=summary'), which implies when those modes apply. But it never names an alternative tool or states when NOT to use this tool versus search/updates, leaving usage largely inferred.

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