RD Station CRM Pipeline Overview

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

Discloses defaults (30-day window, 14-day stall threshold), the funnel-order output, and the error behavior ('errors list all options' when pipeline needs disambiguation). Annotations already mark it readOnly (safe read) and openWorld (account state can change), and the description adds contextual depth without contradicting annotations.

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 paragraphs: what it returns, plus what it's best for, plus quick use-case prompts. Zero wasted words; front-loaded with the core functionality and defaults. Very efficient.

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 report tool with no output schema, it describes return contents, defaults, disambiguation behavior, and typical user intent. The one minor gap is that it doesn't describe return format/structure fields, but for an aggregate report the narrative coverage is strong. No output schema means description must carry some burden, which it does reasonably well.

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% — all three parameters have descriptions in the JSON schema itself (stalled_days, pipeline_name, closed_period_days). The description adds context like defaults for the window and stalled period, but these largely mirror the schema's default values. Baseline 3 is appropriate since the schema already carries the semantic weight.

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?

Specific verb+resource: 'Aggregated health report of a sales pipeline' with detailed breakdown of exactly what it returns (open deal count/value per stage, won/lost counts, win rate, stalled deals). Clearly distinguishes itself from siblings like list_deals (which lists individual deals) by being an aggregate health report.

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?

Provides explicit use cases ('how's my pipeline?', 'where are deals stuck?', 'sales summary for this month') and a clear when-to-use directive: 'fastest way to discover the account's pipelines and stage names/IDs'. This effectively orients agents on when to choose this over deal-level siblings.

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