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, so the safety profile is well covered. The description adds valuable context beyond annotations: keyless access (no auth needed), the gross-vs-net distinction, the 'per employee position' counting convention (double-counts dual-job holders), and that headline fields describe the newest period. This is genuinely useful behavioral information for correct interpretation.

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 efficient and front-loaded, leading with the core function and key data source in one sentence. The PREFER list is somewhat redundant (multiple trigger examples), but the caveats (gross vs net, per position counting) are valuable and earned their space. Slightly verbose due to the repeated trigger phrases, but not wasteful.

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 single-parameter, non-nested tool with strong annotations (readOnly, idempotent, openWorld), the description fully covers the key caveats: source table, keyless access, gross/net distinction, statistical convention (per employee position), and time scope. No output schema exists, but the description's mention of 'recent quarterly trend' and 'headline fields describe the newest' provides sufficient return-shape context for an agent.

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 the quarters parameter is already documented in the schema ('How many recent quarters to include (1-40, default 8)'). The description adds minimal extra meaning for the parameter, though it clarifies that headline fields describe the newest period. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 clearly states the tool retrieves Estonia's average and median monthly gross wage from Statistics Estonia (table PA111), specifing gross vs net, per employee position, and median vs mean distinction. It distinguishes itself from sibling tools by explicitly naming table_meta/query_table/subjects for breakdowns, showing a specific verb+resource+scope.

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 PREFER phrases ('what is the average wage in Estonia', 'Estonian salary', etc.) giving clear trigger intents. It also explicitly states when NOT to use it ('Use subjects/table_meta/query_table for breakdowns by economic activity or county'), naming the alternative tools.

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