Prisjakten.no

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds value by disclosing the aggregation windows and metrics returned (lowest and average price across three periods), which is behavior an agent cannot read off the annotations or schema.

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?

Two sentences, both earning their place: the first states what is returned, the second states when to reach for the tool. The purpose is front-loaded and there is no filler.

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?

There is no output schema, so the description carries the burden of describing results, and it does so by naming the metrics and time windows. For a one-parameter read-only tool, an agent has everything needed to select and invoke it correctly.

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% for the single parameter 'produkt', so the schema already documents it fully. The phrase 'for ett produkt' reinforces the cardinality (one product, not many) but adds no syntax or format guidance beyond the schema. Baseline 3 applies.

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 names a specific resource (prishistorikk) and scope: lowest and average price over 90 days, 6 months and 12 months for one product. That level of detail distinguishes it from the current-price sibling sjekk_pris and from storste_prisfall without naming them. It stops short of explicit sibling differentiation, so 4 rather than 5.

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?

It gives concrete when-to-use triggers: the user asking whether a price is good, whether they should wait, or whether a deal is real. That is unusually actionable guidance. It does not name when-not-to-use cases or point to an alternative tool, which keeps it out of 5 territory.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive). The description adds real behavioral value by disclosing what the result contains — store prices, shipping when available, last-checked time, price-history comparison, and a purchase recommendation — which matters because there is no output schema to convey this.

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?

A single dense sentence that front-loads the core purpose and then layers on the enrichment features. No filler, though the run-on structure with multiple comma-separated clauses is slightly harder to scan than separate sentences would be.

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, read-only lookup with no output schema, the description covers the important ground by explaining what the response includes and that it ends in actionable purchase advice. The main remaining gap is routing guidance against the three sibling tools.

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?

Only one parameter, and schema description coverage is 100%, so the schema fully documents "produkt" as name or brand+model. The description adds nothing about input format or spelling/fuzzy-matching behavior, so baseline 3 is appropriate.

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+resource ("Registrerte butikkpriser for ett produkt") and enumerates the payload: shipping, last-checked timestamp, comparison against price history, and purchase advice. It implicitly separates itself from siblings by scoping to one product, though it never names prishistorikk, sok_produkter, or storste_prisfall to make the boundary explicit.

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 "for ett produkt" scoping implies you use this when you already have a specific product, but there is no explicit when-to-use statement, no exclusions, and no routing to the sibling tools that handle search, raw history, or biggest drops.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds real value by warning that the search timestamp is not the last price-check time and by pointing to sjekk_pris for freshness/shipping — a data-freshness caveat the annotations cannot express.

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?

Four short sentences, front-loaded with the core action, then result content, then routing. Each sentence carries distinct information with no repetition.

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?

There is no output schema, so the description partially compensates by naming the returned fields (prices, store counts). Combined with 100% parameter coverage and full annotations, an agent has enough to call it correctly; pagination/ordering behavior is the only minor omission.

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 both parameters (sporring, antall) are already documented in the schema. The description adds no syntax, format, or query-construction guidance beyond what the schema states, so the baseline 3 applies.

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 ('Søk i katalogen hos prisjakten.no') and adds what the result contains ('registrerte varepriser og antall butikker'). It also explicitly separates itself from the sibling sjekk_pris, so an agent can route without opening either schema.

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?

'Bruk dette først for å finne riktig modell' gives a clear when-to-use condition, and it names sjekk_pris as the alternative for shipping and check time. It does not account for the other siblings (prishistorikk, storste_prisfall), so the routing picture is only partially complete.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value by defining what a 'prisfall' is (kroner saved relative to the previous price), which is behavior beyond the structured fields, but it says nothing about the time window, data freshness or ranking order, leaving gaps for a data-listing tool.

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?

A single front-loaded sentence with no filler — the core output description and the metric definition come first. It is efficient, though the extreme terseness borders on under-specification rather than tightness.

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 simple read-only listing with one optional parameter and no output schema, an agent can call it correctly, but the definition omits the ranking window and freshness of the 'registered' price drops. Given the absence of an output schema, a little more about what the returned entries represent would be warranted.

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?

There is a single optional parameter ('antall') and the schema documents it at 100% coverage with type, default and min/max bounds. The description adds no further meaning about how the count affects the result, so the baseline 3 applies.

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 names the resource and the operation's output (the largest registered price drops in Norwegian webshops) and defines the ranking metric, so an agent knows exactly what it returns. It does not, however, distinguish itself from the siblings prishistorikk, sjekk_pris or sok_produkter, so the agent must infer the boundary itself.

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?

No when-to-use instruction, no prerequisites, and no reference to any alternative tool is given. The agent gets no explicit criteria for choosing this over prishistorikk or sok_produkter.

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