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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds material behavioral context: perfmon stores no history so the result is current state, the meaning of threshold vs fluctuation alerts, and the exact field semantics in each output line. This goes well beyond the structured metadata.

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 dense but purposeful; the first sentence states the core behavior, and later sentences define alert types, output line fields, and parameter defaults. It is longer than average, but the length is justified because there is no output schema to document the return shape.

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 alert-listing tool with no output schema and no required parameters, the description documents the output format (JSONL), field meanings, the two alert categories, entity scoping, and the priority filter. An agent has enough information to invoke it correctly and interpret the response without supplemental documentation.

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 input schema covers 100% of the four parameters, and the description adds value by explaining defaults ('Defaults to High + Critical only'), the threshold/fluctuation subtype semantics, and the campaignIds scoping rule. It also clarifies that PerfmonId and PerfmonDefinitionMetricId identify the underlying per-campaign metric rows.

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 opens with a specific verb and resource: 'Get the currently triggered perfmon alerts (both threshold and fluctuation) for one or more accounts as JSONL.' It names both alert subtypes, so an agent can immediately tell exactly what is returned and can distinguish it from sibling tools such as perfmon_alert_output_table or target_pacing.

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 explicit usage direction: defaults to High + Critical unless minPriority is widened, metricType narrows to one kind, and campaignIds is positioned as 'Use this ONLY to focus on / analyze specific campaign(s)'. It does not name an alternative sibling, but the 'currently triggered ... no history' wording makes the use case clear.

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