Norwegian public data for AI agents: companies, tenders, addresses, laws, exchange rates.
Scored across 18 tools
Tools mostly target distinct resources: get_company vs search_companies vs get_company_units are clearly differentiated. There is some overlap between get_company_tenders and search_tenders (and get_tender vs search_tenders), but descriptions clarify that one is buyer-scoped and the other a general filterable search.
Predominantly consistent verb_noun pattern (get_company, search_laws, get_law_section, search_tenders). Minor deviations like addresses_near and adjust_by_cpi break the pattern slightly but remain readable and unambiguous.
18 tools is slightly heavy but each maps to a distinct data source or query mode (companies, Finnish companies, addresses, laws, statistics, tenders). The count is justified by the multi-domain aggregation scope rather than redundancy.
Covers search+get for companies, Finnish companies, addresses, laws (with section text and navigation), tenders, and key statistics (CPI, population, exchange rates). Minor gaps like company financials or cross-entity linking exist but core lifecycle for each domain is present.
Norwegian addresses from Kartverket within a radius (1 to 1000 m) of a coordinate, nearest first, with distance in metres. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in degrees (WGS 84). | |
| lon | No | Longitude in degrees (WGS 84). | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| radius | No | Search radius in metres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the x402 payment model, exact cost (0.005 USDC per successful call), blockchain (Base), and that errors are free. This is critical pre-invocation context an agent cannot get from 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 dense sentences front-loading the core identity, then the radius/ordering/units, then the cost model. No filler; every clause carries information an agent needs.
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?
Covers data source, geographic constraint, proximity behavior, units, and payment model for a no-output-schema read tool. The main missing piece is pagination context and explicit routing versus search_addresses, but the essentials are present.
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 each parameter's meaning is fully documented in the schema. The description reinforces radius units (metres) but adds nothing beyond what the schema already provides. Baseline 3 is correct.
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 (addresses near a point) with data source (Kartverket), geographic scope (Norwegian), ordering (nearest first), and return unit (distance in metres). Clearly distinguishable from the sibling search_addresses.
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 implies this is a proximity/radius search by naming Kartverket and the radius range, but never explicitly says when to use this versus search_addresses. No exclusions or alternative selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adjusts an amount (rent, salary, contract price) from one month to another by Statistics Norway's consumer price index: amount × index(to) / index(from). Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | The month to adjust to, YYYY-MM. Default: the latest month. | |
| from | No | The month the amount was set, YYYY-MM. Required. | |
| amount | No | The amount to adjust, e.g. 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so safety and repeatability are covered. The description adds important behavioral context by disclosing pricing: 0.005 USDC per successful call via x402 on Base, with errors free.
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 in the first clause, followed immediately by the formula and pricing details. Every sentence adds useful information with no redundancy.
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 calculation tool with rich annotations and fully described parameters, the definition is nearly complete. The return value is implied by the formula rather than explicitly stated, which is a minor gap but not enough to impede correct use.
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, but the description adds meaning by giving the adjustment formula amount × index(to) / index(from). This clarifies the relationship among amount, from, and to beyond the individual schema descriptions.
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: adjusts an amount by Statistics Norway's CPI, with the exact formula. It clearly distinguishes the operation from the sibling get_consumer_price_index, which retrieves index data rather than performing an adjustment.
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 examples of rent, salary, and contract price imply when the tool is useful, but there is no explicit guidance on when to use this instead of get_consumer_price_index or when not to use it. Usage is reasonably inferable but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Norwegian legal entity from Brønnøysundregistrene, cleaned: status (active, bankrupt, winding up, deleted), form, industry (NACE), address, employees, VAT registration. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| orgnr | Yes | 9-digit Norwegian organisation number (mod-11 checked). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world behavior, and the description goes beyond them by disclosing the data provenance and the paid-call model (0.005 USDC per successful call via x402 on Base, errors free). That pricing/auth detail is exactly the kind of context an agent cannot get from 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 compact sentences: the resource plus returned fields first, then the cost model. No filler, no restatement of the tool name, and the most decision-relevant facts are front-loaded.
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 lookup with no output schema, the description compensates by enumerating the returned fields and the cost of a call. It is essentially complete; only the missing sibling routing keeps it from a 5.
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% and the pattern, mod-11 check, and 9-digit format are all documented in the schema itself. The description adds nothing about the orgnr parameter, so the schema-driven baseline of 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 concrete verb+resource ('One Norwegian legal entity from Brønnøysundregistrene') and enumerates the returned facets (status, form, NACE industry, address, employees, VAT). This clearly distinguishes it from siblings like get_finnish_company and search_companies, which cover different registers or list-style queries.
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 single-entity framing plus the required 9-digit orgnr implies a point-lookup use case versus the search_* siblings, but the description never says when to use this over search_companies or get_company_awards/tenders. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public contracts this organisation has won, from Norwegian contract award notices on TED and Doffin (last 180 days): buyer, value, award date and the other winners. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| orgnr | Yes | 9-digit Norwegian organisation number (mod-11 checked). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and idempotent, so safety is covered. The description adds genuinely non-structured behavior: a 0.01 USDC per-successful-call cost model via x402 on Base, and that errors are free. It also discloses the 180-day recency window, though it omits rate limits or result-volume expectations.
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 compact sentences, front-loaded with the core purpose and scoping window before the pricing detail. Every clause carries information, with only minor density in the source/pricing clauses.
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 no output schema, the description helpfully enumerates the return fields (buyer, value, award date, other winners) and the pricing model, and annotations cover the read-only profile. It is nearly complete; absent pagination guidance is mitigated by the fully documented page/size parameters.
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 page, size and the mod-11-checked orgnr are fully documented in the schema. The description adds nothing about parameter format or semantics beyond what the schema provides, making the baseline 3 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 ('Public contracts this organisation has won'), names the data sources (TED and Doffin), the recency window (last 180 days), and the returned fields. An agent can distinguish it from get_company_tenders (open opportunities) 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?
Usage is implied by the resource definition ('contracts won' vs siblings' 'tenders'), but there is no explicit when-to-use/when-not guidance or named alternative for finding open tenders. The agent must infer the routing from the sibling name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public tenders where this organisation is the buyer, linked by organisation number. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | Only tenders whose deadline has not passed. | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| orgnr | Yes | 9-digit Norwegian organisation number (mod-11 checked). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint), and the description adds genuinely non-obvious context: the 0.01 USDC x402/Base payment model and that errors are free. It still omits pagination/result-volume behavior, so it is not a full 5.
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, zero waste, with the resource and scoping constraint front-loaded before the cost note. Nothing could be cut without losing information.
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 list tool with no output schema and fully documented parameters, the description covers identity, scope, and cost. It leaves return shape/pagination unaddressed, but the schema and annotations carry that burden, so it is nearly complete.
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% and each parameter (open, page, size, orgnr) is documented in the schema. The description only implies the orgnr linkage and adds no format or constraint detail beyond what the schema already states, so 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 resource (public tenders) and a precise scope (where this organisation is the buyer, linked by organisation number), which meaningfully distinguishes it from get_company_awards and search_tenders. It does not name a sibling explicitly, so it stops short of a 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?
The 'where this organisation is the buyer' phrasing implicitly scopes usage and hints at the contrast with award-side siblings, but there is no explicit when-to-use/when-not guidance or named alternative for the agent to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The registered business locations (sub-units, underenheter) of a Norwegian company: address, municipality, industry, employees per location, start and closing dates. Locations of sole proprietorships are returned without name or street address. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| orgnr | Yes | 9-digit Norwegian organisation number (mod-11 checked). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world, so the bar is lower, and the description adds genuinely useful context beyond them: x402 pricing (0.01 USDC per successful call, free on error) and the caveat that sole proprietorship locations lack name/street address. It stops short of describing pagination limits or response shape.
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?
Three tight sentences: what is returned, the data caveat, then the cost model. The resource definition is front-loaded with no redundant restatement of the title.
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 no output schema, the description compensates by enumerating the returned fields, plus pricing and a data-completeness caveat. Pagination behavior is delegated to the schema, leaving only minor gaps such as empty-result handling.
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 orgnr format (9-digit, mod-11) and the page/size defaults are already documented. The description adds no pagination or identifier semantics of its own, making the baseline 3 correct.
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: registered business locations (sub-units/underenheter) of a Norwegian company, and enumerates the returned fields. The 'sub-units, underenheter' framing implicitly separates it from get_company, which returns the parent entity.
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 the required orgnr and the resource described, but there is no explicit 'when to use this vs get_company / addresses_near' guidance or stated prerequisites. It never names a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistics Norway's monthly consumer price index (KPI, 2025=100) from 1920 to the latest month. Default: the last 13 months. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last month, YYYY-MM. Default: the latest month SSB has published. | |
| from | No | First month, YYYY-MM. Default: 12 months before to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-redundant behavior: per-call pricing (0.005 USDC via x402 on Base) and that failed calls are free — critical for an agent deciding whether to retry or how to budget. It stops short of describing the response shape or any rate limits.
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?
Three short sentences: data identity first, default scope second, cost third. Every sentence carries information not present in the schema or annotations, and there is no filler or repetition of the tool name.
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 only two optional parameters and no output schema, the description covers what the tool returns (a monthly index on a 2025=100 base), the default range, and the payment implications — enough to call it correctly. The remaining gap is that the response structure (e.g., per-month series vs single value) is left unspecified and there is no output schema to fall back on.
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 'from' and 'to' are already fully documented with patterns and defaults, giving a baseline of 3. The description earns an extra point by stating the resulting span of the defaults ('last 13 months'), which reconciles the two schema defaults into one concrete behavior an agent can reason about.
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?
Names the specific resource (Statistics Norway's monthly consumer price index, KPI), its index base (2025=100), and its temporal span (1920 to latest month). That gives an agent a precise picture of the data returned. It does not explicitly contrast itself with the sibling adjust_by_cpi, so differentiation is implied by resource rather than stated.
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 supplies the default window ('last 13 months') and the cost model, which helps an agent decide whether a call is worth making. However, it never says when to use this raw index versus the sibling adjust_by_cpi, nor any prerequisites (e.g., wallet/auth for x402). Usage is implied by the data type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official Norges Bank exchange rates against the Norwegian krone: the latest business day, one day (a weekend or holiday gives the prior business day) or a daily series up to 366 days, for chosen currencies or all of them. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of a period (YYYY-MM-DD), inclusive. | |
| date | No | One day (YYYY-MM-DD). Default: the latest business day. Not together with from and to. | |
| from | No | Start of a period (YYYY-MM-DD). Needs to; the period is at most 366 days. | |
| currencies | No | Comma-separated ISO 4217 codes, e.g. USD,EUR. Default: every currency Norges Bank publishes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world behavior, and the description adds genuinely non-obvious operational context: 0.005 USDC per successful call via x402 on Base, with errors free. It does not mention wallet/auth prerequisites or rate limits, but the paid-call disclosure is meaningful value beyond the annotations.
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 front-loaded: the capability and its modes come first, the pricing/error policy second. Every clause carries information an agent needs; 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?
With no output schema, the description carries the burden of describing results, and it does so at a high level (latest day vs. daily series) while also covering cost and error behavior. It omits response shape details and handling of invalid or unpublished currency codes, leaving a small gap for a zero-required-parameter tool.
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 earns an extra point by framing the parameters as mode selectors and adding the weekend/holiday fallback rule and the 366-day cap. It stops short of restating syntax like the ISO 4217 comma-separated format, which the schema already covers.
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?
Names a specific verb and resource (official Norges Bank exchange rates against NOK) and immediately enumerates the three supported access modes: latest business day, a single day, or a series up to 366 days. Nothing in the sibling list overlaps, so an agent can identify this tool unambiguously.
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?
Explains the conditions for each mode (one day falls back to the prior business day on weekends/holidays; a series is capped at 366 days) and states the cost model up front. It does not name an alternative tool or explicitly say when not to use it, but there is no competing sibling, so guidance is effectively complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Finnish company from the PRH trade register (YTJ), cleaned: status (active, bankrupt, winding up, ceased), company form, industry (TOL 2008), address, website, other names, EU ID. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | Yes | Finnish business ID (Y-tunnus), e.g. 0112038-9 (mod-11 checked). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds genuinely new behavioral context: a per-call cost of 0.005 USDC via x402 on Base, that errors are free, and that the data is 'cleaned' registry data — none of which appears in 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 tight sentences, front-loaded with the resource and registry source, then the returned fields, then the cost model. The field enumeration is dense but earns its place since there is no output schema.
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 no output schema, the description compensates by listing the returned field set (status values, company form, industry, address, website, names, EU ID). It also discloses cost and error pricing, leaving nothing an agent needs before calling.
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% with a described businessId including the Y-tunnus format, an example and a mod-11 check note. The description adds no parameter-level detail beyond the schema, so the 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 ('One Finnish company from the PRH trade register (YTJ)') and enumerates the fields returned, which makes the payload shape predictable. It does not explicitly contrast itself with the sibling get_company or search_finnish_companies, so an agent must infer the distinction from 'Finnish' and the singular 'One'.
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: 'One Finnish company' hints this is a single-record lookup rather than a search, which helps against search_finnish_companies. There is no explicit when-to-use or when-not-to-use statement, and no routing to alternatives for name-based discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata for one current law or central regulation from Lovdata (title, short title, date, ministry, last change, link to lovdata.no) and its table of contents: section ids, chapters and headings. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lovdata id, e.g. lov/2005-06-17-62 (a law) or forskrift/2010-01-29-72 (a regulation). Put it in the path as written, slash included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint and openWorldHint, so the safety profile is known. The description adds genuinely non-annotation context: the per-call cost (0.005 USDC via x402 on Base), that errors are free, and that only 'current' versions are returned. It does not describe truncation or partial-result behavior, which keeps it short of a 5.
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, no waste, with the payload contents front-loaded and the billing/error semantics trailing. Every clause carries information an agent needs before invoking.
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-only, idempotent tool with no output schema, the description covers what is returned, the currency of the data, and the cost model. The only meaningful gap is not indicating what to use for full text or a single section, which the sibling set implies but the description never says.
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% – the id parameter carries its own pattern, format example, and the advice to include the slash. The description adds no syntax or format detail beyond that, so the baseline 3 for schema-covered parameters 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 ('Metadata for one current law or central regulation from Lovdata') and enumerates exactly what is returned: title, short title, date, ministry, last change, lovdata.no link, plus table of contents with section ids, chapters and headings. It implicitly contrasts with sibling search_laws by scoping to a single entity, but never names that sibling or get_law_section, so differentiation is left partly to inference.
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?
There is no statement of when to use this tool versus search_laws (to find an id) or get_law_section (to fetch a specific section). The word 'one' hints that an id must already be known, but no routing rule or prerequisite is stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full text of one section (§ or artikkel) of a current Norwegian law or regulation, with the ids of the previous and next section. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lovdata id, e.g. lov/2005-06-17-62 (a law) or forskrift/2010-01-29-72 (a regulation). Put it in the path as written, slash included. | |
| section | Yes | Section id as listed in the table of contents: § 3-1, URL-encoded, or just 3-1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description still adds real context: a per-call cost of 0.005 USDC on Base via x402, that only successful calls are charged and errors are free, and that the response includes previous/next section ids.
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?
Three short sentences, front-loaded with what is returned, followed by cost terms. No filler and nothing redundant.
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 no output schema, the description usefully discloses the return shape (full section text plus adjacent section ids) and the billing model. It omits error/rate-limit behavior and authentication requirements for the x402 payment, but is otherwise sufficient for a two-parameter read tool.
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 (id format and section format) are already fully documented in the schema. The description only adds the parenthetical '(§ or artikkel)', which hints at notation variety but adds little beyond the schema's own examples.
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: returns the full text of one section of a current Norwegian law or regulation, and notes the § / artikkel notation. The word 'one section' implicitly separates it from the sibling get_law (whole law), but the alternative is never named, so the differentiation is left to inference.
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: an agent infers it should call this when it needs a specific section rather than a whole law. There is no guidance on prerequisites (e.g. obtaining the Lovdata id via search_laws) or on when get_law would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistics Norway's population on 1 January and the year's births, deaths and migration for the whole country, a county or a municipality, 1951 to the latest year. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year, YYYY. Default: the latest year. | |
| region | No | 0 for Norway, a 2-digit county or a 4-digit municipality number, e.g. 0301 for Oslo. | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld. The description adds genuinely new behavioral context: a per-call cost of 0.005 USDC on Base with free errors, which an agent needs before invoking a paid tool. It stops short of describing rate limits or response shape.
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, front-loaded with the data scope and followed by the pricing note. No redundancy and nothing that could be trimmed without losing information.
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 no output schema, the description carries the burden of explaining returns and does so by naming the four metrics covered. It lacks detail on response structure/units, but is otherwise sufficient for correct invocation of a two-optional-parameter tool.
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. The description adds value beyond the schema by constraining the year parameter to 1951–latest (the schema only enforces a 4-digit pattern) and by naming what data is returned per region/year (population on 1 January plus births, deaths, migration).
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 ('Statistics Norway's population') with explicit geographic granularity (country, county, municipality) and temporal range (1951 to latest year). No sibling tool covers population data, and the title/description make the scope unambiguous.
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?
Implicitly guides usage through scope constraints: one region at a time, years from 1951 to latest, defaulting to the latest year. It does not explicitly state when-not-to-use or point to an alternative, but no sibling tool overlaps, so there is little to disambiguate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One procurement notice with buyer (linked to the company register), CPV codes, regions, deadline and source link. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tender id, e.g. ted:123456-2026 or doffin:2026-105234. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuine value beyond them with the pricing model (0.005 USDC per successful call via x402 on Base, errors free), which an agent needs for cost-aware planning; it omits auth/wallet requirements and rate limits, keeping it short of a 5.
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 compact sentences, both earning their place: the first front-loads what is returned, the second front-loads cost. 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?
With no output schema, the description usefully enumerates the returned fields (buyer, CPV codes, regions, deadline, source link) and the cost model, which is enough for a single-parameter read tool. The only gap is guidance on how to obtain a valid id.
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% and the id parameter already carries a regex pattern plus two worked examples, so the schema does the heavy lifting. The description adds no syntax or format detail beyond it, which is the expected baseline.
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 concrete resource ('one procurement notice') and enumerates the payload fields an agent can expect, so the tool's job is unambiguous. It does not, however, explicitly differentiate itself from search_tenders, which is the obvious sibling an agent could confuse it with.
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?
There is no when-to-use guidance, no mention of the prerequisite of obtaining an id via search_tenders, and no stated exclusions. The singular 'one' implies a by-id lookup, but the agent must infer that entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Norwegian street and cadastral addresses from Kartverket by text, municipality or postcode: coordinates, postcode, municipality, cadastre numbers (gnr/bnr/fnr/snr) and number of units. Costs 0.005 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Address text, e.g. Karl Johans gate 1. | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| postcode | No | 4-digit postcode, e.g. 0154. | |
| municipality | No | 4-digit municipality number (kommunenummer), e.g. 0301 for Oslo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and idempotent, so the safety profile is covered. The description adds genuinely non-obvious behavioral context beyond that: a per-successful-call cost of 0.005 USDC via x402 on Base, and that errors are free — important for an agent deciding whether and how often to call.
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 tight sentences with no filler; the capability and the returned fields come first and the pricing caveat is tacked on at the end. Slightly dense enumeration of gnr/bnr/fnr/snr, but nothing is wasted.
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 no output schema, the description usefully names the returned fields (coordinates, postcode, municipality, cadastre numbers, unit count) and covers the billing model. Pagination (page/size) is left entirely to the schema, which is acceptable for a read-only search tool.
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 schema already documents q, page, size, postcode and municipality with formats and constraints. The description restates the search dimensions but adds no syntax or semantics beyond the schema, so the 3 baseline 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 ('Search Norwegian street and cadastral addresses from Kartverket') and enumerates the query modes (text, municipality, postcode) and returned fields. It implicitly distinguishes itself from addresses_near by being a query/filter search rather than a proximity search, but never names that 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 only implied through the listed search modes; the description never says when to prefer this over addresses_near or any other sibling, nor does it state exclusions. An agent can infer that text/postcode/municipality queries belong here, but must guess for geographic-radius cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Norwegian legal entities by name, municipality, industry code, legal form and status. Sole proprietorships are left out of name searches (they are named after people). Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name, or part of it. | |
| nace | No | NACE industry code or prefix, e.g. 62 or 62.010. | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| status | No | Filter on status. | active |
| org_form | No | Legal form code, e.g. AS, ASA, ENK, NUF, SA, STI. | |
| municipality | No | 4-digit municipality number (kommunenummer), e.g. 0301 for Oslo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so safety is covered; the description goes further with the x402 payment model (0.01 USDC per successful call on Base, errors free) and the sole-proprietorship exclusion, both of which materially affect how an agent should budget and interpret calls. It stops short of rate limits or result-shape expectations.
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?
Three tight sentences: capability, caveat, cost. The scoping facets come first, and the pricing sentence is short and decision-relevant. 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?
For a 7-parameter, no-required-argument search with full schema coverage and no output schema, the description covers scope, an important exclusion, and the payment model. Only pagination/result-volume expectations are left implicit, which the page/size parameters largely carry.
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 schema already explains each of the 7 parameters, including NACE format, municipality code format and defaults. The description adds one genuine semantic point (name searches never match sole proprietorships) but otherwise does not extend parameter meaning beyond 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?
States a specific verb ('Search') and resource ('Norwegian legal entities') and enumerates the five queryable facets, which lets an agent distinguish it from search_finnish_companies and from get_company (single-entity lookup). The Norwegian scope is explicit, not inferred.
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 the facets and by the note that sole proprietorships are excluded from name searches, which is a real retrieval caveat. However, there is no explicit guidance on when to use this versus get_company for details or how to page through to a complete result set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Finnish companies from the PRH trade register by name (current and former names), town or city, company form, industry code (TOL 2008) and postcode. Give at least one filter. Up to 100 hits per page. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name, or part of it. | |
| page | No | Zero-based page. | |
| industry | No | TOL 2008 industry code or prefix, e.g. 62 or 62010. | |
| postcode | No | 5-digit postcode, e.g. 00100. | |
| company_form | No | Company form code, e.g. OY, OYJ, KY, OK, SÄÄ. | |
| municipality | No | Town or city name, e.g. Helsinki. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, idempotent), so the bar is lower. The description adds genuinely non-structured behavior: a 100-hit page cap and a pay-per-call model ('0.01 USDC per successful call (x402, Base). Errors are free.'), which materially affects an agent's decision to call and expected failure handling.
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?
Three dense sentences with zero filler: filters first, then the invocation constraint, then pagination and pricing. Nothing is repeated from the schema or annotations and every clause carries information.
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 6-parameter, zero-required search tool with no output schema, the description covers what can be filtered, the page cap, and the payment mechanics. It stops short of describing what a hit contains or whether pagination beyond the cap is supported, minor gaps given annotations carry the safety profile.
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 baseline is 3. The description still adds value by clarifying that the name search covers 'current and former names' and by naming the register/classification standard (TOL 2008), details the schema's terse 'Name, or part of it' does not convey.
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 Finnish companies from the PRH trade register') and enumerates the exact filter dimensions (name, town/city, company form, TOL 2008 industry code, postcode). It is unmistakably a company search, though it never distinguishes itself from the sibling 'search_companies', so an agent cannot tell the two apart from the description alone.
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?
'Give at least one filter' is an explicit invocation precondition that prevents an unbounded query, and the schema confirms zero required parameters, making this guidance load-bearing. However, no alternative tools (e.g. get_company for a single known company) or when-not conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current Norwegian laws and central regulations from Lovdata by words in the title or in the section text, optionally by type and ministry. Title matches rank first; each result carries up to three matching section snippets, not the full text. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Up to 8 words; all must appear in the title, or all in one section. Leave out to list documents. | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| type | No | Only laws (lov) or only central regulations (forskrift). | |
| ministry | No | Part of the ministry name, e.g. Justis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing ranking behavior (title matches first), the return shape (up to three section snippets, not full text), and the pay-per-call cost model (0.01 USDC per successful call via x402 on Base, errors free). These are exactly the operational facts an agent needs before invoking.
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?
Three sentences, each carrying a distinct load: what is searched, how results are ranked and shaped, and what it costs. Zero filler and the core purpose is front-loaded.
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 no output schema, the description still tells the agent the result shape (up to three matching section snippets, not full text) and ranking. Combined with the fully covered input schema and clear annotations, nothing critical for correct invocation 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 description coverage is 100%, so every parameter is already documented in the schema, including the note that q can be omitted to list documents. The description's 'optionally by type and ministry' merely restates the schema and adds no new syntax or constraints, so 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 precise verb (search) and resource (current Norwegian laws and central regulations from Lovdata), plus the matching surfaces (title words or section text). This clearly distinguishes it from fetch-style siblings like get_law and get_law_section.
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?
Establishes the discovery context (search by words, optional type/ministry narrowing) and contrasts with the siblings by noting results carry only up to three matching section snippets, not full text. It stops short of explicitly naming get_law/get_law_section as the follow-up for full text, so the alternative is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Norwegian public procurement notices from Doffin and TED, filterable by CPV code, region (county or NUTS), deadline and buyer. Costs 0.01 USDC per successful call (x402, Base). Errors are free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words in the title or description. | |
| cpv | No | CPV code or prefix; up to 10, comma-separated. 72 matches all IT services. | |
| open | No | Only tenders whose deadline has not passed. | |
| page | No | Zero-based page. | |
| size | No | Results per page. | |
| region | No | NUTS code (NO, NO08, NO081) or 2-digit county number (fylkesnummer). | |
| buyer_orgnr | No | 9-digit Norwegian organisation number (mod-11 checked). | |
| deadline_to | No | Deadline on or before this date (YYYY-MM-DD). | |
| deadline_from | No | Deadline on or after this date (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds genuinely new behavioral context: a per-successful-call price of 0.01 USDC via x402 on Base, and that errors are not charged. That pricing/billing disclosure is exactly the kind of trait annotations cannot express, though return shape and result volume are left unstated.
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, zero filler, and the most important identifying information (Norwegian public procurement, Doffin and TED) is front-loaded. The pricing caveat is placed second, after the agent knows what the tool is.
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 nine-parameter, all-optional search tool with no output schema, the description covers data sources, filter axes, and billing model, which is most of what an agent needs. The remaining gap is the shape of a result and whether pagination exhausts a result set, and no output schema exists to carry that.
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 every one of the nine parameters is already documented with format and pattern details in the schema. The description restates the filter categories (CPV, region, deadline, buyer) but adds no syntax, defaults, or semantics beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.
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 public tenders) and narrows the domain to Norwegian public procurement notices from Doffin and TED, which is far more informative than the title alone. It enumerates the filterable dimensions, so an agent knows exactly what this tool does. It stops short of naming the closely related sibling get_tender to explain the split, so it is clear but not sibling-differentiated.
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: the enumerated filters (CPV, region, deadline, buyer) signal when this tool is the right one, and the cost note flags that calls are billable. There is no explicit when-to-use or when-not-to-use guidance, and no mention of the singular get_tender sibling for fetching one known notice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
adjust_by_cpiget_company_unitsget_consumer_price_indexget_populationaddresses_nearget_companyget_company_awardsget_company_tendersget_exchange_ratesget_finnish_companyget_lawget_law_sectionget_tendersearch_addressessearch_companiessearch_finnish_companiessearch_lawssearch_tendersNorway's company register (Enhetsregisteret) for AI: lookup, search, name resolution, key financials
Norwegian law for AI: current statutes and central regulations from Lovdata, with source citations
Norwegian company intelligence: ownership, roles, financials, risk, KYC/AML/PEP (multi-source)
Swedish company data (Bolagsverket, SCB) for AI agents, verified, with history and annual reports
Add one secure layer between your agents and this server.
