Search Norwegian companies in the Brønnøysund registers by industry, location, size and revenue. Get profiles, accounts, board, groups and websites. No API key.
Scored across 6 tools
Each tool targets a distinct resource or action: web discovery, industry-code lookup, company profile, financials, group structure, and search. The main soft overlap is between get_norwegian_company (which already includes latest revenue/profit) and get_norwegian_company_financials, but the descriptions make the depth distinction clear enough.
All six names follow a strict snake_case verb_noun pattern (find_/get_/search_ + norwegian_company/industry_codes). The 'norwegian' domain prefix is applied uniformly, making the set highly predictable.
Six tools is well within the ideal 3-15 range and each one covers a real, non-redundant capability of the company-data domain. Nothing feels padded or missing at the structural level.
The surface covers discovery (search), enrichment (websites, industry codes), profile, financials, and group ownership — a strong read-only lifecycle for a public registry. Minor gaps exist, such as reverse lookup by person (CEO/board member) or role-based queries, which agents would have to work around.
Find the websites of one to five Norwegian companies and the platform each runs on, such as Shopify or WooCommerce. Checks the registered website, the domain of the registered email and domains guessed from the company name, and confirms ownership by finding the organisation number or full company name on the site. For each company returns the website with its source, evidence and confidence (or null); the site platform: shopify_theme, shopify_headless or shopify_headless_likely with the theme, another store platform such as woocommerce, magento, nopcommerce, mystore or 24nettbutikk, a site builder or CMS such as wix, squarespace, webflow, wordpress, custompublish or odoo, a Norwegian store platform such as retailhub, a headless content platform (sanity, contentful), nextjs for other custom builds, or unknown with the generator tag; and every address checked. site.shopify is true for any Shopify storefront. Some sites block automated requests and read as unreachable. Takes up to about 15 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| organizationNumbers | Yes | One to five organisation numbers, such as one search page split up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it lists the sources checked, the ownership-confirmation method, the returned evidence and confidence fields, the platform taxonomy, the Shopify flag, and the caveat that some sites block automated requests and read as unreachable. It also notes the approximate runtime.
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 and the description is information-dense, with the long platform enumeration earning its place because there is no output schema to explain return values. It is somewhat dense and list-heavy, but not wasteful given the tool's complexity.
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 web-discovery tool with no output schema, the description covers the main return fields, platform categories, evidence sources, confidence values, and unreachable-site caveat. It could be more complete by explaining confidence semantics or source values, but it gives enough for correct selection and invocation.
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 single parameter is already fully documented in the schema, including the nine-digit format and one-to-five item limit. The description reinforces the company-count scope but adds no new syntax or format details 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?
The description states a specific verb and resource: finding websites and platforms for one to five Norwegian companies. It clearly distinguishes this from sibling tools that retrieve company registry, financial, group, or industry-code data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when this tool is appropriate by describing the website discovery and platform classification job, including the one-to-five company scope. It does not explicitly name sibling alternatives or state when not to use it, 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.
Look up SN2025 industry codes (the Norwegian NACE standard the register uses) by Norwegian or English words or a code prefix. Use the codes in search_norwegian_companies; a broader code such as 62 includes all its subclasses.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it is a SN2025 reference lookup, accepts Norwegian or English words and code prefixes, and returns hierarchical codes where broader codes include all subclasses.
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 wasted words. The core purpose is front-loaded, followed by the practical routing instruction and hierarchy caveat.
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 reference lookup with annotations covering safety and no output schema, the description gives enough to call it correctly and use the result. It could be slightly more complete by sketching the return shape, such as a list of matching codes with labels, but the essential context is 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 0% for the single required query parameter, so the description must compensate. It does so by explaining that query accepts Norwegian or English words or a code prefix, which is meaningful guidance for forming valid inputs, though it omits details like case sensitivity or exact prefix format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Look up SN2025 industry codes') and immediately clarifies the acronym ('the Norwegian NACE standard the register uses'), so an agent knows exactly what this tool returns. It also distinguishes itself from company-focused siblings by routing the result into search_norwegian_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use the retrieved codes in search_norwegian_companies and explains the hierarchy rule that a broader code such as 62 includes subclasses. What is missing is an explicit statement of when not to use this tool, such as when free-text company search is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full profile of one Norwegian company by organisation number: register details, contact information, activity, CEO, board, auditor and accountant, and the latest filed revenue and profit.
| Name | Required | Description | Default |
|---|---|---|---|
| organizationNumber | Yes | Nine-digit Norwegian organisation number, such as 923609016. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description still adds value by disclosing the substantive payload (board, auditor, accountant, latest filed revenue/profit) which an agent could not infer from annotations, though it is silent on not-found handling and data freshness beyond 'latest filed'.
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?
One dense sentence, front-loaded with the operation and key, followed by the returned field groups. No filler and nothing 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 enumeration of returned sections is the right compensating detail and makes the tool callable with confidence. The remaining gap is sibling overlap — an agent cannot tell from this description whether financials require a separate call.
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 single parameter has a pattern plus an example (923609016), so the schema already does the work. The description only restates that lookup is keyed on organisation number, adding no format or validation detail beyond the schema — baseline 3.
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 ('Full profile of one Norwegian company') and enumerates exactly what is returned: register details, contact, activity, CEO, board, auditor, accountant, revenue and profit. It does not, however, distinguish itself from the sibling get_norwegian_company_financials, which presumably also returns revenue/profit.
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 'by organisation number' phrasing implies a direct single-record lookup, so intended usage is inferable. But there is no explicit when-to-use guidance, no mention of when to prefer get_norwegian_company_financials or get_norwegian_company_group, and no statement about behavior for unknown organisation numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to three years of filed annual accounts for a Norwegian company: revenue, operating and net profit, payroll, assets, equity, debt and cash, with growth, margin and equity ratio. Set consolidated for group accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| consolidated | No | Return the group (konsern) accounts instead of the company accounts; only parent companies file them. | |
| organizationNumber | Yes | Nine-digit Norwegian organisation number, such as 923609016. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond that: the data source is filed annual accounts and coverage is capped at three years, which tells the agent to expect sparse or missing history for young or non-filing companies.
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 that opens with the scope constraint and then enumerates returned fields without filler. The field list is somewhat dense, but every item conveys what the caller will receive.
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 correctly carries the burden of describing returns by naming the fields and derived ratios, and it covers the one optional parameter. Minor gaps remain: currency/units and what is returned when no accounts are filed are 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 coverage is 100%, so both parameters (including the consolidated/konsern distinction and the nine-digit format) are already fully documented in the schema. The description only restates the consolidated flag, adding no syntax or format detail, 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?
States a specific verb and resource (annual accounts for a Norwegian company) plus the exact metrics returned, so an agent knows precisely what comes back. It does not name or distinguish itself from siblings like get_norwegian_company or get_norwegian_company_group, so it falls 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 clause 'Set consolidated for group accounts' gives one conditional usage hint, but there is no guidance on when to pick this over get_norwegian_company or get_norwegian_company_group, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The corporate group (konsern) a Norwegian company belongs to: the top parent and every subsidiary with ownership share. Accepts any member of the group.
| Name | Required | Description | Default |
|---|---|---|---|
| organizationNumber | Yes | Nine-digit Norwegian organisation number, such as 923609016. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations stating it is read-only, the description provides significant behavioral context by defining the complexity of the return value—it returns a whole hierarchical group rather than a single entity.
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 description is brief and highly dense with information. Both sentences are necessary and immediately front-load the key feature: the inclusion of both parent and subsidiaries.
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?
Since there is no output schema, the description is complete enough to inform the agent exactly what complex data structure it should expect back, making it highly actionable.
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?
Given the schema is 100% covered, the description adds value by explaining the operational context of the required 'organizationNumber' (i.e., it can be any member ID, not just the root).
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 clearly identifies the resource being retrieved (corporate group/konsern) and defines its scope (top parent and all subsidiaries), distinguishing it from tools that might only return basic company data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies that the tool accepts input for 'any member of the group,' which is a critical piece of usage guidance, letting the agent know it does not need to already know the ultimate parent to use the tool successfully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Norwegian companies in the Brønnøysund register by industry, municipality, legal form, employees, founding or registration date, website pattern and filed accounts, with optional revenue bounds. Returns name, organisation number, industry, employees, address, website, email and phone. Active companies only unless includeInactive is set. Get industry codes from find_norwegian_industry_codes first. totalMatches counts register matches before any revenue filter; with a revenue filter only the current page is checked, so continue with nextPage for more.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| page | No | Zero-based page. | |
| sort | No | relevance keeps the register's name ranking. Defaults to relevance when name is given, otherwise employees_desc (largest first). | |
| website | No | ||
| pageSize | No | Companies per page, up to 50. Defaults to 20. | |
| foundedTo | No | Date as YYYY-MM-DD. | |
| foundedFrom | No | Date as YYYY-MM-DD. | |
| postalCodes | No | Four-digit postal codes of the business address. | |
| maxEmployees | No | Maximum employees: 0, 4 or 5 and above. | |
| minEmployees | No | Minimum employees: 0, 1 or 5 and above. The register hides exact counts from 1 to 4. | |
| registeredTo | No | Date as YYYY-MM-DD. | |
| industryCodes | No | SN2025 industry codes from find_norwegian_industry_codes: a section letter (G), division (47), group (47.9) or full code (47.910). Older SN2007 codes match nothing. | |
| maxRevenueNok | No | Maximum revenue in NOK in the latest filed accounts; filtered like minRevenueNok. | |
| minRevenueNok | No | Minimum revenue in NOK in the latest filed accounts; companies filing in another currency do not match. Revenue is not searchable in the register: each page of candidates is fetched, then filtered, so a page can return fewer matches than pageSize. Narrow with employee bounds that fit the revenue range, and continue with nextPage. | |
| vatRegistered | No | ||
| municipalities | No | Municipality names (Oslo, Bergen) or four-digit numbers (0301), matched on business or postal address. | |
| registeredFrom | No | Earliest registration date; use it to find new companies. | |
| includeInactive | No | Include bankrupt companies and companies being wound up. Defaults to false. | |
| organizationForms | No | Legal forms such as AS (private limited), ASA (public limited), ENK (sole proprietorship), NUF (foreign branch), DA, ANS, SA or STI. | |
| lastFiledAccountsYears | No | Only companies whose latest filed annual accounts are from these years. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent), and the description goes well beyond them: inactive/bankrupt companies are excluded unless includeInactive is set, revenue is not register-searchable so filtering is page-local, and companies filing in a foreign currency silently fail to match. It also discloses the totalMatches-before-revenue-filter subtlety, which is exactly the kind of non-obvious behavior an agent could misread.
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 purpose then filters, returns, defaults and caveats in five compact sentences with no filler. Minor waste: the totalMatches and revenue-filter-paging points restate schema text, and 'continue with nextPage' names a field that does not exist in the schema (the parameter is 'page').
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 20 optional parameters and no output schema, the description still tells the agent what comes back (name, org number, industry, employees, address, website, email, phone) and how paging behaves under a revenue filter. Nothing material is missing for correct invocation.
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 already 85%, so baseline is 3; the description adds cross-parameter meaning a per-field schema can't easily convey, notably that industry codes must come from find_norwegian_industry_codes and how the revenue bounds interact with paging. It does not add anything for name, postalCodes, vatRegistered or lastFiledAccountsYears 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?
Opens with a specific verb+resource ('Find Norwegian companies in the Brønnøysund register') and then enumerates the exact filter surface (industry, municipality, legal form, employees, dates, website pattern, filed accounts, revenue bounds). It also states the returned fields and the active-only default, so an agent can tell this is the bulk-search tool rather than the single-record get_norwegian_company 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?
Gives real routing advice: get industry codes from find_norwegian_industry_codes first, and how to proceed when a revenue filter is applied. It lacks an explicit 'when not to use / use the sibling instead' statement against get_norwegian_company or find_norwegian_company_websites, which is the only gap.
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.
find_norwegian_company_websitesfind_norwegian_industry_codesget_norwegian_companyget_norwegian_company_financialsget_norwegian_company_groupsearch_norwegian_companies
Add one secure layer between your agents and this server.