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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only scope exclusions and nothing about what the status contains, whose team is returned, or whether membership/auth is required — meaningful behavioral gaps remain for a read tool.

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 short and front-loads the trigger condition, which is good. But the two negative clauses are oddly domain-specific (medical, meditation chat) for a team-overview tool, reading like boilerplate that consumes space without clarifying tool selection.

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 no output schema, the description is the only place an agent could learn what a "team status" returns, and it says nothing. Combined with an ambiguous notion of "team" and no pointer to related tools, the definition leaves the agent guessing before invocation.

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 single `tap` parameter has full schema description coverage explaining it comes from keep_progress and may be left empty, so the schema carries the semantics. The description adds nothing about the parameter, which is acceptable at 100% coverage but earns no bonus.

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?

"Use this when the user asks how their team is doing" conveys a status/overview intent for a team resource, but the verb is implicit and "how their team is doing" is ambiguous — it could mean progress, activity, or membership. It does not clearly separate this from siblings like get_session_status, my_progress, or my_history.

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 an explicit trigger condition (user asks how their team is doing) and explicit exclusions, so usage is partially guided. However, the exclusions are domain guardrails (medical, emergencies, meditation chat) rather than routing to alternative tools, so an agent gets no help choosing between this and other team/progress tools.

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