Open guide to businesses in any country, plus Norwegian public services and parties. Never ranks.
Scored across 5 tools
Each tool targets a distinct domain: website AI readiness, business registry lookup, business discovery, political party stances, and public services. The only potential confusion is between check_business (official registry lookup) and find_business (discovery of AI-verified businesses), but their descriptions clearly differentiate them.
Four tools follow a verb_noun pattern (check_business, find_business, find_political_party, find_public_help) in snake_case, but ai_check uses a noun_verb pattern. This is a minor deviation, and all names are readable and consistent in casing.
Five tools is well-scoped for a guide covering AI readiness, business lookup, political information, and public services. Each tool has a clear purpose, and no tool feels redundant or missing at this count.
The set covers key retrieval tasks: website analysis, business registry lookup, AI business discovery, political party stances, and public services. Minor gaps exist, such as no tool to search the guide's own content or retrieve general AI information, but core workflows are covered.
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?
Goes well beyond the read-only/openWorld annotations: it discloses the return shape (score out of 100, points per check, concrete actions), the runtime (5–15 seconds), and the nuanced scoring rule that blocking training bots costs only 5 of 20 points while blocking user-fetch bots costs 15. That is substantial behavioral context an agent cannot infer from structured fields.
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?
Purpose is front-loaded and the dense paragraph is mostly information-bearing, with the scoring model and runtime carrying real value. A few clauses are long and could be tightened, but there is little pure 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 explaining returns and does so (score, per-check points, concrete actions). Combined with runtime, the check set, and profile semantics, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains each yardstick's scope (government = public bodies, organisation = NGOs/associations, party = political parties, media = news media) and that detection happens unless profile is supplied. That exceeds the raw enum list.
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 (checks) and resource (how a public website looks to AI assistants), then enumerates the exact things examined (robots.txt, sitemap, schema.org, llms.txt, ai-catalog.json, prompt-injection text). This is clearly distinguishable from the find_* and check_business 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?
Gives clear context for the profile parameter ('Optional yardstick. Leave out to detect it from the site') and explains the scoring model, so the agent understands when a profile override matters. It does not explicitly contrast with the sibling check_business or state exclusions, so it stops short of 5.
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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value by enumerating the returned payload (name, legal form, industry, address, bankruptcy/winding-up), which matters because there is no output 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?
A single front-loaded sentence: verb, source registry, lookup keys, then returned fields. No filler, no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only lookup with no output schema, the description covers the input keys and the shape of the result. It is only missing routing information relative to its siblings.
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 (name, org_number) are already fully documented with their semantics. The description adds nothing beyond restating that either key can be used, 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 ('looks up'), specific resource ('a Norwegian business in Enhetsregisteret'), and the two lookup keys are named. It stops short of distinguishing itself from the sibling find_business, which appears to overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the sibling find_business, and no exclusions or prerequisites. The 'by organisation number or name' phrasing merely restates what the schema's parameter descriptions already say.
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 cover read-only/idempotent/non-destructive/closed-world, and the description adds genuinely new behavioral facts: results are returned in random order, the guide does not rank them, and two of the results are FICTIONAL test entries. The fictional-results disclosure is especially valuable for preventing the agent from presenting fake businesses as real. Pagination/result-count behavior is still 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?
Purpose is front-loaded in the first clause, with result-ordering and fictional-example caveats following. The parenthetical detail about the bakery in Bodø and the bilingual Bergen guesthouse is slightly verbose but serves a real disambiguation purpose.
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, three-parameter search with full annotation coverage and no output schema, the description covers corpus scope and result-ordering semantics. It omits result limits and whether empty result sets are possible, 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%, so need, country, and postal_code are already well documented (including 'leave out to search all countries'). The description adds nothing parameter-specific beyond that, which is the expected baseline when the schema carries the load.
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 gives a specific verb (finds) and resource (businesses in the guide that can help with a need) and characterizes the corpus (verified AI-business-card registrants plus two fictional examples). It does not explicitly distinguish itself from siblings like check_business or ai_check, 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?
Usage is implied by 'can help with a need' and by the scope note about the guide, so an agent can infer this is the need-based discovery entry point. However, no when-not-to-use condition or named alternative (check_business, ai_check, find_public_help) is given.
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 already declare readOnlyHint=true, idempotent, non-destructive, and closed-world. The description adds useful ordering behavior (alphabetical, never ranked) and a completeness caveat (not complete yet; missing party is not less relevant) that annotations do not cover. With annotations covering safety, this is strong added context, though return format details are minimal.
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?
Front-loaded with the core purpose and use case, then constraints, then presentation guidance. Every sentence carries information, though the answer-formatting instructions are somewhat verbose for a simple lookup tool.
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 100% schema coverage and no output schema, the description covers purpose, usage, and key behavioral caveats (ordering, incompleteness). It is nearly complete, though it could briefly note the return structure given there is no output schema.
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 single parameter (name) is already documented with example and behavior (omit to list all). The description adds no parameter-level syntax or formatting details beyond what the schema provides, 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+scope: what Norwegian parties say themselves about a topic, drawn from their own pages. It clearly distinguishes itself from siblings like find_business or find_public_help, which target different domains. An agent can tell exactly what this tool returns 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?
Explicitly says to use it for political questions about party positions, and instructs how to present results: give each party's view in its own words with a link and do not take sides. This is active, prescriptive guidance on when and how to invoke and report.
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 declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful context — it is an open index of state agencies and municipalities with no commercial ranking — but says nothing about result format, coverage limits, or what happens when topic/municipality are omitted.
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 the return value and scope front-loaded and the differentiation note at the end. No filler, no 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?
For a simple read-only lookup with no output schema, the description covers what is returned (links) and the two axes of the index (topic, municipality). It is nearly complete; only the shape/limits of the returned link set and behavior when both optional params are omitted are left unstated.
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 enum plus both field descriptions are already documented in the schema, including the municipality/topic pairing hint. The description adds no syntax, format, or default-value detail beyond what the schema provides, 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 (returns links) and resource (free public services in Norway), plus the scope of the index (state agencies by topic, all 357 municipalities). The closing clause 'Public services are never ranked against businesses' implicitly separates it from find_business/check_business 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?
The description implies the domain (free public services, not businesses) but never explicitly says when to choose this over find_business or check_business. The instruction to pair municipality with the municipality topic lives in the schema, not the description, so no when-to-use guidance is added here.
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_helpNorwegian public data for AI agents: companies, tenders, addresses, laws, exchange rates.
Norway's company register (Enhetsregisteret) for AI: lookup, search, name resolution, key financials
Norwegian company search, accounts, roles, groups and websites from Brønnøysund, remote MCP.
Company search and enrichment from official business registers in 200+ countries.
Add one secure layer between your agents and this server.