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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description is not burdened with safety disclosure. It still adds real behavioral context: the search backend accepts synonyms ('bensinpris', 'euro', 'gull', 'oslo') and tolerates ø/æ typed as o/ae, and it states the result shape (title, canonical URL, headline number).

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 search-routing sentence is front-loaded and useful, but the entire content is duplicated in Norwegian and English, roughly doubling length without adding information for a tool-selecting agent. The first sentence also mixes capability detail into a slot where the primary purpose should sit.

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?

An output schema exists, so return values need not be re-specified, yet the description still names the returned fields and points to get_page for the full numbers with sources and dates. For a two-parameter search tool with full annotation coverage and a high-coverage schema, nothing an agent needs to invoke it correctly is missing.

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%, so both parameters are already documented with examples and the 1–25 bound. The description goes beyond the schema by disclosing that the query is matched against synonyms and that diacritics are normalized (ø/æ as o/ae), which materially changes how an agent should phrase the query string.

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?

States a specific verb and resource ('Search the pages of pristavla.no ... with the site's own search') and identifies the domain as a Norwegian price-comparison site. It is clearly distinguishable from siblings like get_page and list_pages, which address a single page or enumerate pages rather than run a query.

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?

Explicitly routes the agent onward: 'Use get_page on a result for the full numbers, with sources and dates,' which tells the agent this tool returns shallow results and where the deep data lives. It does not address when to prefer list_pages or get_series instead, so it stops short of a full when/when-not/alternative treatment.

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