Brreg MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting different resources (companies, subunits, municipalities, roles, organization forms, NACE codes) or actions (search vs. get). However, the multiple organization-form tools (get_organization_forms, get_organization_forms_for_units, get_organization_forms_for_subunits, get_organization_form) could be slightly confusing, though their descriptions clarify the different scopes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, using 'get_' for single resource retrieval and 'search_' for query operations. There are no mixed conventions or vague verbs, making the naming highly predictable.
Tool Count4/5
With 18 tools, the server is slightly on the higher end of the ideal range, but each tool serves a distinct purpose within the Norwegian Business Registry domain. The count feels justified given the variety of reference data (municipalities, organization forms, roles) and core entities (companies, subunits, updates).
Completeness4/5
The tool surface covers the main read-only workflows for the Brreg API: retrieving companies, subunits, roles, updates, and reference data. Minor gaps exist, such as no direct endpoint for listing a company's subunits, but these can be worked around with search_subunits. The inclusion of reference data and services makes the set fairly comprehensive.
Average 3.2/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 provides no information about pagination, data scope, return format, or any other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it merely restates the tool name. It does not add structured context or earn its place beyond the name. It is under-specified rather than effectively concise.
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?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description provides minimal context. It fails to explain what 'organization forms' are, how pagination works, or what the response looks like, leaving a significant gap for the agent.
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?
The schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional meaning, but the baseline of 3 applies as the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get organization forms for subunits' clearly states the verb (Get) and the resource (organization forms for subunits), distinguishing it from sibling tools like 'get_organization_forms_for_units' and 'get_organization_forms'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or context for choosing this tool over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states that filters are optional, which is already apparent from the schema. It does not reveal whether the operation is read-only, how results are returned, or any pagination/sorting behavior beyond what the schema lists. This is a significant transparency gap.
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, short sentence with no redundant or extraneous information. It front-loads the primary purpose and everything stated is relevant. It is appropriately concise for the level of detail it provides.
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?
The tool has 8 parameters, no annotations, and no output schema. The description does not explain what the response contains, how updates are defined, or how the filters relate to each other. While the schema covers parameter formats, the description fails to provide essential high-level context needed for an agent to fully understand the tool's behavior and output.
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?
The schema description coverage is 100%, so the base score is 3. The tool description itself adds no parameter-level meaning beyond what the schema already provides. It does not compensate for any gaps because there are none, but it also does not enhance understanding of the parameters.
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 uses a clear verb+resource pattern ('Get updates for companies'), immediately conveying the tool's function. It implicitly distinguishes from the sibling tool get_subunit_updates by specifying 'companies' rather than 'subunits', though it does not explicitly reference alternatives. The phrase 'with optional filters' adds a hint of flexibility without detail.
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 provides no guidance on when to use this tool versus alternatives like get_subunit_updates or search_companies. It does not offer any context about intended use cases, prerequisites, or exclusions. The only implied usage is from the resource name itself, which is not sufficient per the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It does not mention that pagination is supported (via page/size parameters) or that 'get all' is per-page rather than a full dump. No information about auth, performance, or edge cases is given, which is a notable gap for a tool that returns a list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant wording. It earns its place by stating the core purpose, though it could be more informative without becoming verbose. Structure is clean and front-loaded.
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 list tool with pagination parameters and no output schema, the description is underspecified. It does not explain that results are paginated, what the return format is, or how to handle sorting. Given the presence of sibling tools, additional context on when to use this versus related tools would improve completeness. The description is minimal for the tool's actual complexity.
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 three parameters (page, size, sort). The description adds no extra semantic value beyond the tool name; it neither clarifies parameter formats nor provides usage examples. Baseline of 3 applies since the schema fully covers the parameters.
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 tool retrieves all organization forms, distinguishing it from the singular 'get_organization_form' and the scoped variants ('for_units', 'for_subunits'). However, it does not explicitly name these siblings or elaborate on the exact scope (e.g., all forms across all units), leaving some ambiguity about when this differs from the scoped tools.
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?
No guidance is provided on when to use this tool versus alternatives like get_organization_forms_for_units or get_organization_form. The reader is left to infer that 'all' implies a global list, but without explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', which implies read-only, but does not mention pagination, sorting, permissions, or any side effects. The description provides minimal behavioral transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose without any fluff. It is well-structured and front-loaded, though it may be too minimal in content. Still, for conciseness, it is effective.
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?
Given the lack of annotations, no output schema, and ambiguous relationship to sibling tools, the description is incomplete. It does not clarify what 'main units' refers to, how this tool differs from similar ones, or what the return structure looks like. The context is insufficient for an agent to confidently select and invoke the tool.
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?
The input schema has 100% coverage with descriptions for all three parameters (page, size, sort), so the schema carries the parameter semantics. The description adds no extra meaning beyond what the schema already provides, which meets the baseline for high schema coverage.
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 ('Get') and the resource ('organization forms') with a scope ('for main units'), which is specific and understandable. However, it does not explicitly distinguish this tool from siblings like get_organization_forms_for_subunits or get_organization_forms, relying on the name for differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as get_organization_forms_for_subunits or get_organization_forms. The description does not mention any exclusions, prerequisites, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the general action and does not mention return format, pagination behavior, default filtering semantics, or whether includeChanges defaults to false. The schema provides parameter details but not behavioral context.
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, front-loaded sentence with no filler. It immediately states the purpose without wasting words. While short, it is appropriately concise for its role when the schema carries detailed parameter info.
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 tool with 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what a 'subunit update' contains, how pagination works, or when to prefer this over sibling tools. The minimal text leaves significant context gaps.
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 baseline is 3. The description's 'optional filters' adds minimal extra meaning since all parameters are already marked optional (no required params). The schema handles parameter semantics; the description does not add substantive value beyond this.
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 identifies the action ('Get') and the resource ('updates for subunits'). It distinguishes from siblings like get_subunit (which fetches a single subunit) and get_company_updates (which targets company updates), though it does not explicitly name these alternatives.
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 provides no guidance on when to use this tool versus alternatives such as get_company_updates or search_subunits. The phrase 'with optional filters' is redundant given the schema and does not clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior, but it only says 'various filters' without mentioning pagination, sorting, response shape, or how filters like hierarchical industry codes work. The description adds no behavioral context beyond what the name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary elaboration. It is front-loaded with the action and resource, though 'various filters' is somewhat vague and could be more specific without adding length.
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?
Given 15 parameters, no annotations, and no output schema, the one-sentence description is insufficient. It does not explain return values, pagination, or when to prefer this over sibling search tools, leaving significant gaps for an agent trying to use the tool correctly.
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%, with detailed parameter descriptions covering constraints and examples, so the tool description does not need to restate each filter. The baseline of 3 applies because the schema fully documents the parameters; the description itself adds no extra semantic value.
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 tool searches for companies in the Norwegian Business Registry, using the specific verb 'Search' and a defined resource. While it does not explicitly contrast with sibling tools like search_subunits or get_company, the 'search' vs 'get' distinction is implied.
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?
No guidance is provided on when to use this tool versus alternatives such as get_company or search_subunits. The existence of filters implies a broad search use case, but the description does not state this or give any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Get all municipalities' without revealing pagination behavior, result ordering, response format, or any limits. The schema implies pagination via page/size, but the description is silent on this, making 'all' potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, but it is under-specified for a tool with pagination and sorting parameters. While concise, it sacrifices necessary context, so it does not earn a higher score.
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?
Given the presence of pagination and sorting parameters, no output schema, and no annotations, the description is incomplete. It fails to explain that the result is paginated, what fields are returned, or how sorting affects the output, leaving significant gaps for an agent using this tool.
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?
All three parameters (page, size, sort) have descriptions in the schema, achieving 100% coverage. The tool description adds no additional semantic value beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all municipalities' uses a specific verb (Get) and resource (municipalities), and the word 'all' distinguishes it from sibling get_municipality, which targets a single entity. This clearly states the tool's primary action and scope.
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?
No guidance is given on when to use this tool versus alternatives like get_municipality or search_municipalities. The description does not mention any conditions, prerequisites, or scenarios where it is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, but it only states that it retrieves all role types. It does not mention read-only behavior, permissions, pagination, sorting, or any side effects. This is a significant gap for a zero-annotation tool.
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, concise sentence with no filler or redundant detail. It is immediately front-loaded and communicates the core action and resource effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is minimally viable but lacks context about return format or how it relates to sibling tools. It fulfills the basic function but leaves the agent to infer practical usage details, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the baseline for zero parameters is 4. The description adds no parameter info because none are needed, so it appropriately meets this baseline.
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 'Get all role types' clearly states a specific verb ('Get') and resource ('all role types'), making its purpose evident. It distinguishes itself from siblings like 'get_role_group_types' and 'get_company_roles' by indicating a global scope, though it does not explicitly call out those alternatives.
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?
There is no guidance on when to use this tool versus alternatives like 'get_role_group_types' or 'get_company_roles'. No context is provided for typical use cases, prerequisites, or situations where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only says 'get' without disclosing return format, error behavior, read-only nature, or any limitations. This is minimal and not transparent.
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 extremely concise and front-loaded with the essential action and target. It is a single short sentence with no wasted words, satisfying conciseness requirements.
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?
With no output schema, no annotations, and minimal description, the agent lacks information about return values, possible errors, or expected usage context. This is insufficient for a complete understanding of the tool's behavior.
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?
The schema fully describes the single parameter (municipalityNumber with type string and explanation 'Municipality number (4 digits)'), so schema coverage is 100%. The description adds no additional meaning beyond that, giving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a clear verb 'Get' with a specific resource 'municipality' and specifies selection by municipality number. This distinguishes it from sibling 'get_municipalities' (plural) and other tools like 'get_company'.
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?
No guidance is provided about when to use this tool versus alternatives such as get_municipalities or search_companies. The description only states what it does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral details beyond the obvious read operation. It does not mention return format, response size, pagination, or any potential side effects, leaving the agent without risk context.
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, concise sentence with no fluff. Every word is necessary and directly conveys the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple (0 params, no output schema), but the description provides no additional context such as what a role group type is or how this relates to the sibling get_role_types. It is minimally viable but lacks any clarifying context to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter details. This is the baseline score for tools with no parameters, as the input schema is already complete and simple.
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 'Get all role group types' clearly states the action (get), the resource (role group types), and scope (all). However, it does not differentiate from the sibling tool get_role_types, leaving ambiguity about whether these are distinct concepts.
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?
No guidance is provided about when to use this tool versus alternatives like get_role_types or get_company_roles. The description only states what it does, with no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral transparency. The description merely restates the name and gives no additional behavioral context, such as whether the operation is read-only, if there are any side effects, pagination, or what format the results take. Since 'get' implies a read operation, there is no explicit disclosure of any additional behavioral traits.
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, concise sentence: 'Get all role representatives.' Every word is necessary and there is no fluff. It is front-loaded with the verb and resource, and the structure is appropriate for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no annotations, no output schema), the description provides the minimum viable context: it states the action and the resource. However, it does not explain what 'role representatives' are, what the output looks like, or any nuances that would help the agent understand the tool's role among the many sibling tools. This is a clear gap for a tool without an output schema, so it is not more than minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% schema coverage trivially), and the baseline for 0 parameters is 4. The description does not need to add parameter semantics because none exist. Thus, it meets the baseline without providing extra parameter information.
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 'Get all role representatives' clearly identifies the action (get) and the resource (role representatives), and the phrase 'all' suggests a comprehensive list. However, it does not distinguish itself from sibling tools like get_company_roles or get_role_types, which may also relate to roles, so it lacks sibling differentiation that would push it to a 5.
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?
There is no guidance on when to use this tool versus any of the siblings. The description only states what the tool does, not in what context it should be chosen. For example, it does not mention that it is the only tool for fetching representatives, or that it should be used when no filters are needed. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It merely states 'Search for subunits' without explaining pagination behavior, result format, filtering semantics, default limits, or potential errors. This leaves the agent with significant unknowns.
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, front-loaded sentence that states the core function without unnecessary words. It earns its place.
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?
Given 8 controllable parameters, no output schema, and no annotations, the description is too terse. It fails to explain how filters combine, what the response contains, or how pagination behaves, leaving the agent under-informed for a moderately complex search tool.
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?
The input schema covers all 8 parameters with descriptions, so baseline is 3. The tool description adds no parameter-specific meaning, but the schema is already comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Search'), the resource ('subunits'/'business units'), and the scope ('Norwegian Business Registry'). It distinguishes from siblings like search_companies and get_subunit by specifying the subunit resource.
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?
No guidance is provided on when to use this tool versus alternatives such as search_companies or get_subunit. The description does not mention any exclusions, prerequisites, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. However, it merely restates the action implied by the name ('get') and adds 'by code' which is a parameter detail, not a behavioral disclosure. It does not mention error handling (e.g., not found case), read-only nature, or any other behavioral traits beyond what is obvious.
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, concise sentence that immediately conveys the purpose. No unnecessary words or repetition. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool without an output schema, the description is largely sufficient. It clearly states the function. However, it could be slightly more complete by noting that it returns a single record and contrasting with the plural sibling, but given the simplicity, it is nearly complete.
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% with 'Organization form code (e.g., AS, ENK, ASA)', so the schema fully documents the parameter. The description's 'by code' adds nothing beyond the schema. Baseline score of 3 is appropriate as the description provides no extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a specific organization form by code, distinguishing it from sibling 'get_organization_forms' which lists forms. The verb 'get' and resource 'organization form' are specific, and 'by code' adds the lookup scope.
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?
No guidance on when to use this tool versus alternatives. It doesn't mention that this is the singular version and should be used when a specific code is known, or that 'get_organization_forms' is for listing all. No exclusions or alternative references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and source, but does not disclose response format, authentication needs, pagination, or any side effects. It is not misleading but is minimal.
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, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter, low-complexity tool, the description is minimal but adequate. However, with no output schema, it does not describe what the response contains or provide any additional context that would help the agent fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with complete coverage. The description need not add parameter details, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'all available services from the Brreg API', clearly distinguishing it from sibling tools that fetch companies, municipalities, roles, etc. The scope is explicit ('all available services'), making the tool's purpose unambiguous.
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 offers no guidance on when to use this tool versus the many sibling tools. It does not mention alternatives, exclusions, or appropriate scenarios, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. The verb "Get" strongly implies a read-only operation, and the scope ("for a specific company") adds context. However, it does not explicitly state permission requirements, error behavior, or lack of side effects, which would be expected when annotations are absent.
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, front-loaded sentence that states exactly what the tool does without any unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, single-parameter retrieval tool with no output schema. The description clearly states that it returns all roles for a company, which is sufficient for basic invocation. It could mention the return type (e.g., an array) or any limitations, but the simplicity and schema coverage make the description almost complete.
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?
The input schema has 100% coverage for the single parameter (organizationNumber, described as 9 digits). The description adds only the vague qualifier "specific company," which does not meaningfully enhance the schema's description. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Get" and clearly states the resource: "all roles for a specific company." This distinguishes it from sibling tools like get_role_types (which lists role types) and get_role_representatives (which lists representatives), making its purpose and scope unambiguous.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or scenarios where other role-related tools might be more appropriate. The absence of any usage context means the agent has to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral aspects. It only says 'detailed information' without specifying what fields are returned, possible errors, or authentication requirements. This leaves significant ambiguity for a read operation.
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 sentence that efficiently conveys the core action, resource, and lookup key. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description is adequate but thin. It does not explain what 'detailed information' includes or how this differs from related company tools like get_company_roles or get_company_updates, leaving some gaps in completeness.
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?
The schema already fully describes the only parameter (organizationNumber, 9 digits). The description merely restates 'by organization number' without adding new meaning, so it matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching detailed information about a company using its organization number. The verb 'Get' combined with 'specific company' distinguishes it from search-oriented or role-specific sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use when you have an organization number and need company details. It does not explicitly mention alternatives like search_companies or get_company_roles, but the single-parameter design strongly implies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description only states the function and hierarchical filtering support; it does not mention result limits, pagination, ordering, or whether empty search text returns all codes. For a search tool, this lack of behavioral detail leaves an agent uncertain about what to expect from invocations.
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, front-loaded sentence with no redundant or filler content. It efficiently conveys the core purpose and a key capability (hierarchical filtering) without wasting the agent's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and hierarchical filtering, but with no output schema, it does not disclose the structure of search results (e.g., whether results include code, name, hierarchy path). The includeNotes and includeHierarchy parameters hint at response content, but the description itself does not confirm what a typical result looks like or if results are truncated or paginated. This is a moderate gap for a search tool.
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?
The input schema provides 100% coverage with detailed descriptions for all 6 parameters, including level ranges, exact codes, parent codes, and defaults for boolean flags. The tool description adds no additional parameter semantics beyond what the schema already offers, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' with a clear resource 'NACE industry codes' and includes differentiators like 'hierarchical filtering support' and 'full SN2025 classification'. This distinguishes it from sibling tools such as search_companies, which search companies, and get_municipalities, which retrieve municipal data. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when searching for NACE industry codes, especially with hierarchical filtering needs. Although it does not explicitly name alternatives, the sibling list contains no other NACE code search tool, so the context is clear. It does not provide explicit when-not-to-use guidance, but the distinct resource type makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' implies a safe read-only operation without side effects, and the description conveys that. However, it doesn't disclose what 'detailed information' includes, potential error cases (e.g., invalid organization number), or any rate limits, so it adds limited insight beyond the tool name and schema.
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, front-loaded sentence that states the verb, resource, and lookup criterion without any filler. Every word contributes to the meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is adequate. It clearly identifies the tool's purpose and input. It doesn't enumerate the returned fields, but 'detailed information' is a reasonable generic description for a getter, and the sibling tool list provides context for what 'subunit' might encompass.
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?
The schema has 100% coverage for the single parameter 'organizationNumber' with a description stating 'Organization number (9 digits)'. The description repeats the parameter's role but doesn't add extra meaning beyond the schema, so it meets the baseline for well-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('detailed information about a specific subunit'), and the lookup key ('by organization number'). This distinguishes it from sibling tools like get_company (which targets companies) and search_subunits (which searches rather than retrieves a specific subunit).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you have an organization number and need specific subunit details. It doesn't explicitly exclude alternatives or name when to prefer search_subunits, but the 'by organization number' phrasing makes the usage scenario unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![brreg-mcp-server MCP server](https://glama.ai/mcp/servers/daveHylde/brreg-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/daveHylde/brreg-mcp-server)

Score Badge

Copy to your README.md:

[![brreg-mcp-server MCP server](https://glama.ai/mcp/servers/daveHylde/brreg-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/daveHylde/brreg-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/daveHylde/brreg-mcp-server'

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