Skip to main content
Glama
reidar80

Norwegian Business Registry MCP Server

by reidar80

search_sub_entities

Search for Norwegian business sub-entities (underenheter) using filters like name, organization number, parent entity, employee count, registration dates, industry codes, and organizational forms to find specific subsidiaries or branches.

Instructions

Search for Norwegian business sub-entities (underenheter) with various filters

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
navnNoSub-entity name (1-180 characters)
navnMetodeForSoekNoSearch method for name parameter
organisasjonsnummerNoList of organization numbers (9 digits)
overordnetEnhetNoParent entity organization number
fraAntallAnsatteNoMinimum number of employees
tilAntallAnsatteNoMaximum number of employees
registrertIMvaregisteretNoRegistered in VAT registry
fraOppstartsdatoNoStart date from (ISO-8601 yyyy-MM-dd)
tilOppstartsdatoNoStart date to (ISO-8601 yyyy-MM-dd)
fraDatoEierskifteNoOwnership change date from (ISO-8601 yyyy-MM-dd)
tilDatoEierskifteNoOwnership change date to (ISO-8601 yyyy-MM-dd)
fraNedleggelsesdatoNoClosure date from (ISO-8601 yyyy-MM-dd)
tilNedleggelsesdatoNoClosure date to (ISO-8601 yyyy-MM-dd)
organisasjonsformNoOrganizational forms
hjemmesideNoWebsite
kommunenummerNoMunicipality numbers
naeringskodeNoIndustry codes
sizeNoPage size (default 20)
pageNoPage number
sortNoSort field and order

Implementation Reference

  • Core handler function in BrregApiClient that executes the tool logic by making an API request to the BRREG underenheter endpoint using the shared makeRequest method.
    async searchSubEntities(params: SubEntitySearchParams = {}) {
      return this.makeRequest('/enhetsregisteret/api/underenheter', params);
    }
  • TypeScript interface defining the input parameters for the search_sub_entities tool, extending EntitySearchParams and adding specific date filters for sub-entities.
    interface SubEntitySearchParams extends Omit<EntitySearchParams, 'konkurs' | 'underTvangsavviklingEllerTvangsopplosning' | 'underAvvikling' | 'underKonkursbehandling'> {
      fraOppstartsdato?: string;
      tilOppstartsdato?: string;
      fraDatoEierskifte?: string;
      tilDatoEierskifte?: string;
      fraNedleggelsesdato?: string;
      tilNedleggelsesdato?: string;
    }
  • Registration of the search_sub_entities tool in the ListToolsRequest handler, including name, description, and detailed inputSchema.
      name: "search_sub_entities",
      description: "Search for Norwegian business sub-entities (underenheter) with various filters",
      inputSchema: {
        type: "object",
        properties: {
          navn: { type: "string", description: "Sub-entity name (1-180 characters)" },
          navnMetodeForSoek: { type: "string", enum: ["FORTLOEPENDE"], description: "Search method for name parameter" },
          organisasjonsnummer: { type: "array", items: { type: "string" }, description: "List of organization numbers (9 digits)" },
          overordnetEnhet: { type: "string", description: "Parent entity organization number" },
          fraAntallAnsatte: { type: "number", description: "Minimum number of employees" },
          tilAntallAnsatte: { type: "number", description: "Maximum number of employees" },
          registrertIMvaregisteret: { type: "boolean", description: "Registered in VAT registry" },
          fraOppstartsdato: { type: "string", description: "Start date from (ISO-8601 yyyy-MM-dd)" },
          tilOppstartsdato: { type: "string", description: "Start date to (ISO-8601 yyyy-MM-dd)" },
          fraDatoEierskifte: { type: "string", description: "Ownership change date from (ISO-8601 yyyy-MM-dd)" },
          tilDatoEierskifte: { type: "string", description: "Ownership change date to (ISO-8601 yyyy-MM-dd)" },
          fraNedleggelsesdato: { type: "string", description: "Closure date from (ISO-8601 yyyy-MM-dd)" },
          tilNedleggelsesdato: { type: "string", description: "Closure date to (ISO-8601 yyyy-MM-dd)" },
          organisasjonsform: { type: "array", items: { type: "string" }, description: "Organizational forms" },
          hjemmeside: { type: "string", description: "Website" },
          kommunenummer: { type: "array", items: { type: "string" }, description: "Municipality numbers" },
          naeringskode: { type: "array", items: { type: "string" }, description: "Industry codes" },
          size: { type: "number", description: "Page size (default 20)" },
          page: { type: "number", description: "Page number" },
          sort: { type: "string", description: "Sort field and order" }
        }
      }
    },
  • MCP tool dispatcher case in CallToolRequestSchema handler that calls the searchSubEntities method and returns the JSON-formatted results.
    case "search_sub_entities":
      const subEntityResults = await apiClient.searchSubEntities(request.params.arguments as SubEntitySearchParams);
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(subEntityResults, null, 2),
          },
        ],
      };
  • Shared helper method used by searchSubEntities (and other tools) to construct and execute HTTP requests to the BRREG API.
    private async makeRequest(endpoint: string, params?: Record<string, any>): Promise<any> {
      const url = new URL(`${BASE_URL}${endpoint}`);
      
      if (params) {
        Object.entries(params).forEach(([key, value]) => {
          if (value !== undefined && value !== null) {
            if (Array.isArray(value)) {
              url.searchParams.set(key, value.join(','));
            } else {
              url.searchParams.set(key, String(value));
            }
          }
        });
      }
    
      const response = await fetch(url.toString(), {
        headers: {
          'Accept': 'application/json',
        },
      });
    
      if (!response.ok) {
        if (response.status === 404) {
          throw new McpError(ErrorCode.InvalidRequest, `Resource not found: ${endpoint}`);
        }
        throw new McpError(ErrorCode.InternalError, `API request failed: ${response.status} ${response.statusText}`);
      }
    
      return response.json();
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching with filters but doesn't describe what the tool returns (format, structure), pagination behavior (implied by 'size' and 'page' parameters but not explained), rate limits, authentication requirements, or error conditions. This is inadequate for a search tool with 20 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex search tool with 20 parameters and no output schema, the description is insufficient. It doesn't explain what results look like, how pagination works, or provide any behavioral context. With no annotations and no output schema, users must infer too much from the parameter descriptions alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all 20 parameters thoroughly. The description adds only the general concept of 'various filters' without providing additional semantic context beyond what's in the parameter descriptions. This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search for') and target resource ('Norwegian business sub-entities (underenheter)'), providing specific domain context. However, it doesn't explicitly differentiate from sibling tools like 'search_entities' or 'get_sub_entity', which would be needed for a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'with various filters' which implies filtering capabilities, but provides no explicit guidance on when to use this tool versus alternatives like 'search_entities' or 'get_sub_entity'. No context about use cases, prerequisites, or limitations is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/reidar80/BRREG-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server