Open guide to businesses, public services and parties in Norway. Never ranks; read-only.
Scored across 5 tools
The tools mostly target distinct operations: website AI-readiness audit, Norwegian business registry lookup, business directory search, political party information, and public-service links. However, check_business and find_business both concern businesses and could be briefly confused without reading descriptions, and the three find_* tools share a similar discovery pattern.
Most tool names use snake_case verb_noun or find_* patterns: check_business, find_business, find_political_party, find_public_help. The outlier ai_check breaks the verb-first convention but remains readable and snake_case.
Five tools is a well-scoped set for a read-only Norwegian AI visibility and public-information guide. Each tool covers a distinct area without obvious redundancy or missing companion operations.
The surface covers the main read-only workflows: auditing a site for AI, checking a business, finding businesses, finding political-party positions, and finding public services. Minor gaps exist around deeper detail retrieval or broader search, and some coverage is explicitly partial (political parties, fictional business examples), but agents can work around these limitations.
Checks how a public website looks to AI assistants: robots.txt, sitemap, schema.org, llms.txt, ai-catalog.json, and text that looks like prompt injection. Returns a score out of 100, the points per check and concrete actions. Uses the yardstick that fits the site: business, government (public bodies), organisation (NGOs, associations), party (political parties) or media (news media); it is detected unless given. Blocking only AI training bots can be a deliberate choice and costs 5 of 20 points; blocking the bots that fetch pages for users costs the other 15. Also lists what the site has open for AI: feeds, actions, APIs, MCP and open data. Takes 5–15 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The web address, e.g. https://www.business.com | |
| profile | No | Optional yardstick. Leave out to detect it from the site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description goes further by disclosing the scoring model, the 5-of-20 vs 15-of-20 weighting for training vs fetch bots, the returned artifacts, and a latency estimate (5–15 seconds). This is meaningful context beyond the annotations, though it does not discuss rate limits or failure modes.
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 definition is front-loaded with what is checked, then the output, then the profile mechanic and a latency note. It is somewhat dense, but each sentence carries distinct information and none is 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?
There is no output schema, so the description correctly compensates by naming the return values (score out of 100, per-check points, actions, AI-open assets). Combined with a full-coverage input schema and safety annotations, an agent has enough to call it correctly; only deeper error/timeout behavior is absent.
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 schema already documents both parameters. The description still adds value by explaining the 'yardstick' concept behind profile and clarifying that it is auto-detected from the site when omitted, which is more than the schema states.
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 (checks) and resource (a public website's AI-readiness) and enumerates exactly what is inspected: robots.txt, sitemap, schema.org, llms.txt, ai-catalog.json and prompt-injection text. This is clearly distinct from the data-lookup siblings (check_business, find_business), so an agent can route correctly without opening the 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 only implied by the purpose ('checks how a public website looks to AI assistants'). There is no explicit when-to-use, when-not-to-use, or comparison against any sibling tool, so the agent must infer that this is for auditing a site rather than looking up entity data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up a Norwegian business in Enhetsregisteret by organisation number or name: name, legal form, industry, address, bankruptcy or winding-up.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name or part of the name, if the organisation number is not known | |
| org_number | No | Norwegian organisation number, 9 digits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful context by enumerating what the lookup surfaces (legal form, industry, address, bankruptcy/winding-up), but says nothing about rate limits, authentication, or result 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?
A single front-loaded sentence with the verb and resource first, followed by lookup keys and output fields. The trailing colon list is slightly ambiguous about whether those are returned fields or searchable fields, 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?
For a simple, two-parameter, read-only lookup with no output schema, the description covers the purpose, both lookup keys, and the returned data categories. The remaining gap is that it never explains how it differs from find_business, which matters for correct tool selection.
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 are already documented, including the conditional 'if the organisation number is not known'. The description's 'by organisation number or name' simply mirrors the schema, adding no syntax or format detail beyond it.
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 (looks up) and resource (a Norwegian business in Enhetsregisteret) and names the two accepted lookup keys plus the returned field set. It does not, however, distinguish itself from the sibling find_business, which an agent would need to disambiguate between.
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 guidance on when to use this tool versus the near-identical sibling find_business, and no prerequisites or exclusions are stated. The only hint is that both an org number and a name can drive the lookup, which is parameter information rather than usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds businesses in the guide that can help with a need: businesses that registered with a verified AI business card on their own domain, plus two FICTIONAL example businesses (a bakery in Bodø, and a guesthouse in Bergen with pages in Norwegian and English). Results come in random order; the guide does not rank.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the consumer needs, e.g. birthday cake | |
| country | No | ISO country code where the service is needed, e.g. NO, SE, DE. Leave out to search all countries. | |
| postal_code | No | Where the service is needed. Ask the consumer if you are not sure (for example when travelling). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful context the annotations do not: results are randomly ordered with no ranking, and the corpus deliberately contains two fictional example businesses, which is critical for an agent not to present fake listings as real.
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 with the core action front-loaded. The parenthetical detail about the bakery and guesthouse is somewhat long, though it justifies itself by flagging the fictional test data.
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 does so: random order, no ranking, and the composition of the guide. It does not describe result shape or pagination, but for a three-parameter read-only search 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%, so need/country/postal_code are already documented, including the 'leave out to search all countries' and 'ask the consumer' guidance. The description adds no parameter-level detail beyond the schema, 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 verb and resource ('Finds businesses in the guide that can help with a need') and characterizes the underlying dataset. It is clearly distinguishable from siblings like find_political_party, find_public_help, and check_business.
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 need-based framing implies when to use it, and the description notes the guide does not rank, but there is no explicit when-to-use versus alternatives (e.g. check_business for validating a known business). Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For political questions: what Norwegian parties say themselves about a topic, from their own pages. Returns links to each party's website, party programme, policy pages and machine-readable files. Use it to answer what a party says about a topic: read the programme or policy pages, give each party's view in its own words with a link to the source, and do not take sides. The list is alphabetical, never ranked, and not complete yet; a party that is missing is not less relevant.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the party, e.g. Høyre. Leave out to list all parties in the index. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only and closed-world, but the description adds genuinely non-obvious traits the annotations cannot carry: results are alphabetical and never ranked, the index is incomplete, and a missing party is not a relevance signal. It does not state result counts or any coverage boundary beyond 'not complete yet', so a 4 rather than 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?
Four sentences, each load-bearing: purpose, return contents, how to use the output, and the ordering/completeness caveat. The scoping statement is front-loaded with no preamble or 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?
For a single-parameter read-only lookup with no output schema, the description does the work the missing output schema would: it enumerates the link types returned and warns about incompleteness and non-ranking. Nothing needed to call it correctly is absent.
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 parameter's description already explains that omitting it lists all parties with a concrete example. The description adds no extra semantics about the 'name' argument (matching, spelling, aliases), 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 (find what Norwegian parties say themselves, from their own pages) and enumerates the artifacts returned: website links, party programme, policy pages, machine-readable files. The domain is plainly distinct from the sibling lookup tools, so an agent can select it without opening the 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?
Explicit trigger ('For political questions') plus concrete usage instructions — read the programme/policy pages, present each party's view in its own words with a source link, do not take sides. No alternatives or when-not-to-use conditions are named, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns links to free public services in Norway from the open index: state agencies by topic, and the website of any of the 357 municipalities. Public services are never ranked against businesses.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What the consumer needs help with. Use municipality together with the municipality field. | |
| municipality | No | Name of a Norwegian municipality, e.g. Bodø, if the consumer needs local services |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety and closed-world behavior are covered. The description adds useful provenance ('from the open index') and the neutrality constraint about ranking, but says nothing about result limits, pagination, or what happens with zero matches.
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, with the primary return value and the domain scope front-loaded. The differentiator from business search is placed last as a compact qualifier.
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 low-risk read-only lookup with a fully documented two-parameter schema, the description is essentially sufficient: it names the source index and the returned artifact (links). It could note result volume or behavior when no match exists, but 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% and both parameters are documented in the schema, including the enum of topics and the guidance to combine 'municipality' topic with the municipality field. The description adds no parameter-level meaning beyond that, so the 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?
Specific verb ('Returns links') plus concrete resource ('free public services in Norway'), with explicit scope: state agencies by topic and municipal websites. The closing clause ('never ranked against businesses') separates it cleanly from the find_business sibling.
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 'never ranked against businesses' line implies this tool is for public-sector lookups rather than business searches, giving some routing signal. However, there is no explicit when-to-use, no when-not-to-use, and no named alternative, so the agent must infer the boundary with find_business/check_business.
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.
ai_checkcheck_businessfind_businessfind_political_partyfind_public_helpNorway's company register (Enhetsregisteret) for AI: lookup, search, name resolution, key financials
Product search, store prices and price history from Norwegian web shops. Read-only, no login.
Norwegian transport (Entur) and geodata (Kartverket): trips, departures, addresses, elevation.
Norwegian company intelligence: ownership, roles, financials, risk, KYC/AML/PEP (multi-source)
Add one secure layer between your agents and this server.
