Pristavla – Norwegian prices / norske priser

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds a genuine behavioral disclosure beyond them: rows whose source does not allow reuse are omitted and named in notes, which tells the agent the result set may be incomplete and why.

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 content is dense and front-loaded, leading with what is returned. However, the entire description is duplicated in Norwegian and English, doubling the length so that every sentence is paid for twice rather than earning its place once.

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 one-parameter read tool with an output schema and full annotation coverage, the description is nearly complete: input format is exemplified and the reuse-omission rule is explained. Return-value details are somewhat redundant given the output schema, but nothing needed to call 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 the baseline is 3, and the description goes beyond it with multiple worked slug examples (including nested paths like 'strom/ostlandet') and the meaning of the empty string as the front page.

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 ('Get one page's numbers exactly as the page shows them') with an enumeration of what is returned: headline number, summary, dates, main table with source URL and check date, licence and citation. It implicitly separates itself from list_pages and search by scoping to a single page, though it never names a sibling explicitly.

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?

Usage is implied rather than stated: five concrete slug examples and the note that a full pristavla.no URL also works tell the agent how to call it, but there is no guidance on when to choose this over get_series, list_pages or search.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: answers are silently truncated to the newest rows when long, and the data is licensed and sourced. It does not quantify the truncation threshold, but the key surprise (row loss on large queries) is disclosed.

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 structure is sensible — general behavior first, then a dataset catalog — and each catalog entry carries useful information. But the entire preamble is duplicated verbatim in Norwegian and English, roughly doubling length for no informational gain; the duplication is the main waste.

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?

With an output schema present and annotations carrying the safety profile, the description only needs to explain selection and scoping, which it does thoroughly via the dataset catalog and the truncation note. The remaining gap is operational: it never states the row ordering, the threshold that triggers truncation, or how limit interacts with it.

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 baseline is 3, but the description adds meaning the schema lacks: each enum value is expanded with what the table contains and its exact period coverage (e.g. 'valuta-dag ... 2025-09-23–2026-11-02'), which is essential for choosing a dataset and valid from/to values. It still says nothing extra about the filter column names per dataset, which would require schema knowledge.

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 rows from one of the open tables under pristavla.no/data/', and immediately narrows scope (optionally bounded by period, filtered on column values). It then enumerates the exact datasets with contents and temporal coverage, so an agent knows precisely what this tool returns versus the page-oriented siblings.

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?

Usage is only implied through scope: this is the tabular-data accessor, so an agent can infer it is not the tool for pages or free-text search. However, get_page, list_pages and search are never named, and there is no explicit 'use X instead when Y' guidance or statement of when filtering vs. date-bounding is appropriate.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds that it is a listing with folder/kind filtering, which is useful context, but says nothing about pagination behavior despite limit/offset parameters. With annotations doing the heavy lifting, a 3 is appropriate.

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 purpose is front-loaded, which is good, but the entire description is duplicated in Norwegian and English, effectively doubling its length for the same content. The long kind list is also repeated verbatim from the schema enum. Functional but not 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 filtered-list tool with an existing output schema, the description covers purpose, returned fields, and filter options, and annotations cover safety. The notable gap is pagination: limit/offset are neither explained in the description nor in the schema, which an agent listing potentially hundreds of pages would need. Otherwise complete enough.

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 50%: kind and prefix are documented in the schema, while limit and offset are not. The description compensates partly by giving concrete folder-prefix examples ('kommunale-avgifter', 'valuta', 'bolig') and enumerating the kind values, but it never explains the limit/offset pagination semantics. Marginal added value over the schema.

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 states a specific verb and resource ('List the pages of pristavla.no') and enumerates the returned fields (title, URL, kind, date, headline number), so the agent knows exactly what the tool produces. It does not explicitly name or contrast itself with siblings like get_page or search, but the list-vs-get distinction is largely self-evident. Clear purpose, no explicit sibling differentiation.

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?

Usage is implied by 'optionally filtered by folder prefix or kind,' which tells the agent filtering is available. However there is no explicit when-to-use or when-not-to-use guidance and no reference to alternatives such as search or get_page for single pages. Adequate but leaves routing to inference.

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 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.