get_multi_team_pulse

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral detail beyond that: parallel execution via asyncio.gather, graceful degradation for failed boards, an org-wide aggregate in the output, and default limit differences from the single-board version. This is exactly the kind of context that helps an agent predict side effects and performance.

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 longer than average but every sentence earns its place: the opening two sentences explain the core behavior and performance advantage, the middle covers failure handling and output structure, and the Args list is a dense, well-parsed reference. No fluff remains, though it could be tightened slightly by moving the Args block into a more compact form.

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 read-only, aggregated reporting tool, the description covers everything an agent needs: what it does, how it handles failures, what the output contains (aggregate + per-board summaries), the output formats (report/json), and the exact semantics of every parameter. The existing output schema and annotations cover the rest. No critical gap is apparent.

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 0%, so the description carries the full burden of parameter explanation. It does so comprehensively: every parameter (boards, horizon_days, lookback_days, limit, format, max_idle_days, max_overdue_days, instance) is described with its purpose, default, and special behaviors (e.g., 'Pass 0 to disable'). This far exceeds the bare schema and enables correct invocation.

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 specific verb 'get' with a clear resource 'multi_team_pulse' and immediately distinguishes it from sibling get_team_pulse by noting it operates in parallel across multiple boards with an aggregated org-wide view. This is a precise, non-tautological purpose that an agent can act on.

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 references get_team_pulse as the single-board counterpart and explains the parallel fan-out, making it clear this is the multi-board variant. It also notes that failed boards are listed but do not abort the operation, giving practical context. However, it does not explicitly state 'use this when you need multiple boards' as a hard rule, so it stops short of a full when/when-not guide.

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