nordic-registry-mcp-server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

A "release" on Glama is not the same as a GitHub release. To create a Glama release:
1. if you haven't already.
2. Go to the Dockerfile admin page, configure the build spec, and click Deploy.
3. Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
Read the detailed guide
Disambiguation4/5
Tools are generally well-differentiated by country and resource type, with clear distinctions like norway_get_roles vs norway_get_signature_rights. However, some overlap exists between search and get tools across countries, which could cause minor confusion if an agent misinterprets the purpose of each.
Naming Consistency5/5
All tool names follow a consistent pattern of country_prefix_verb_noun (e.g., denmark_get_company, norway_search_companies). This structured naming makes it easy to predict tool functions and navigate the set without ambiguity.
Tool Count4/5
With 19 tools, the count is reasonable for covering multiple Nordic countries and various company registry operations. It might be slightly high, but each tool serves a distinct purpose, such as handling different countries or specific queries like updates and subunits, justifying the scope.
Completeness5/5
The tool set provides comprehensive coverage for company registry data across Denmark, Finland, and Norway, including CRUD-like operations (get, search), specialized queries (roles, updates, subunits), and utility functions (municipalities, org forms). No obvious gaps are present for the domain.
Average 4.4/5 across 19 of 19 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on May 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds that it returns 'the owning company's details,' which gives context about output content. However, it doesn't disclose additional behavioral traits like error conditions, rate limits, or authentication requirements beyond what annotations provide.
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 with two clear sentences: one stating the purpose and another about the return value. It's front-loaded with the core functionality and wastes no words. Every sentence earns its place by adding value beyond the tool name.
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?
Given the tool's low complexity (single required parameter), rich annotations (readOnly, openWorld, idempotent), and existence of an output schema, the description is reasonably complete. It covers what the tool does and what it returns. The main gap is lack of sibling differentiation, but overall it provides enough context for basic understanding.
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 the single parameter 'p_number' documented as 'required.' The description adds that it's for a 'production unit P-number,' providing semantic context about what the parameter represents. This aligns with the baseline score of 3 when schema coverage is high, as the description adds some meaning without duplicating schema 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 clearly states the tool's purpose: 'Get parent company for a production unit P-number. Returns the owning company's details.' It specifies the action (get), resource (parent company), and input (production unit P-number). However, it doesn't explicitly differentiate from sibling tools like 'denmark_get_company' or 'denmark_get_production_units', which might have overlapping functionality.
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. With multiple Denmark-specific sibling tools (denmark_get_company, denmark_get_production_units, denmark_search_by_phone, denmark_search_companies), there's no indication of when this P-number lookup is preferred over general company searches or production unit queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the FI prefix auto-removal behavior and clarifies what data is returned in summary vs. full modes. While annotations already indicate readOnly, openWorld, and idempotent characteristics, the description provides specific implementation details that help the agent understand how the tool behaves.
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 perfectly concise and front-loaded: two sentences that efficiently cover identifier handling, default behavior, and parameter effect. Every word earns its place with zero redundancy or wasted text.
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?
Given the tool's moderate complexity, good annotations, and existence of an output schema, the description provides sufficient context. It covers the key operational details (identifier format, data modes) while relying on structured fields for safety characteristics and return format documentation.
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?
With 50% schema description coverage (only 'business_id' has a description), the description compensates well by explaining the 'full' parameter's effect on returned data. It clarifies that 'full=true' returns complete data with previous names and registry entries, adding meaningful semantics beyond the bare boolean schema definition.
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's purpose: 'Get company by Y-tunnus' with specific details about identifier format and data returned. It distinguishes from sibling tools by specifying Finnish companies and Y-tunnus format, though it doesn't explicitly contrast with other Finnish tools like 'finland_search_companies'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'Y-tunnus' format and the 'full' parameter option, but doesn't explicitly state when to use this versus alternatives like 'finland_search_companies' or other country-specific company lookup tools. It provides some guidance on parameter usage but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating safe, cacheable operations. The description adds valuable context beyond this: it discloses caching behavior ('Cached 24h'), which isn't covered by annotations. This enhances transparency about performance and data freshness, though it could mention more about rate limits or error handling.
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 highly concise and front-loaded: it states the core purpose in the first clause, adds behavioral context (caching), and provides a practical example. Every sentence earns its place without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, annotations covering safety, and an output schema likely detailing the codes), the description is complete. It explains what the tool does, its caching behavior, and includes an example, which is sufficient for an agent to understand and invoke it correctly without needing to delve into output details.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output and usage. It adds semantic value by explaining what the tool returns (municipality codes) and providing an example, which compensates for the lack of parameter details.
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's purpose: 'Get Norwegian municipality codes for filtering searches.' It specifies the resource (Norwegian municipality codes) and the intended use (filtering searches). However, it doesn't explicitly differentiate from sibling tools like 'norway_list_org_forms' or 'norway_search_companies', which might also involve Norwegian data filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'for filtering searches' and provides an example ('Oslo = 0301'), suggesting it's used to map municipality names to codes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'norway_search_companies' or 'norway_get_company', which might involve similar filtering but for different data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating safe, non-destructive, and repeatable operations. The description adds valuable behavioral context beyond annotations: it discloses pagination details (20 results per page default, max 100, use page parameter for more), which is not covered by annotations. No contradictions with annotations.
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 front-loaded with the core purpose, followed by pagination details in a single, efficient sentence. Every part adds value without redundancy, making it appropriately sized and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with pagination), rich annotations (readOnlyHint, openWorldHint, idempotentHint), and the presence of an output schema (which handles return values), the description is complete enough. It covers key behavioral aspects like pagination, which complements the structured data effectively.
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 33% (only 'cvr' has a description), with 3 parameters total. The description adds meaning for 'page' and 'size' by explaining pagination behavior (e.g., 'Use page parameter for more results'), but does not fully detail 'size' constraints or 'cvr' format. It compensates partially for low schema coverage, aligning with the baseline expectation.
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 verb 'Get' and the resource 'production units (P-numbers) for a Danish company by CVR', which is specific and distinguishes it from siblings like 'denmark_get_company' (which gets company info) or 'denmark_search_companies' (which searches). It explicitly mentions the target resource and identifier.
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 for when to use this tool: to retrieve production units for a Danish company using a CVR. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for basic usage. Sibling tools like 'denmark_get_by_pnumber' suggest alternatives for different queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, and idempotent operations, the description adds that '+45 prefix auto-removed' (formatting behavior) and 'Not all companies have registered phones' (coverage limitation). This provides practical usage information that annotations don't cover.
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 yet complete - just two sentences that each provide essential information. The first sentence states the core purpose, the second provides two critical behavioral notes. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (single parameter, read-only operation), the presence of comprehensive annotations, and the existence of an output schema, the description provides exactly what's needed. It covers purpose, key behavioral notes, and limitations without unnecessary detail.
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?
With 100% schema description coverage, the schema already documents the single required 'phone' parameter. The description adds marginal value by mentioning the '+45 prefix auto-removed' behavior, but doesn't provide additional semantic context about the phone parameter beyond what's implied in the schema.
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 purpose: 'Find Danish company by phone number.' It specifies the resource (Danish company) and the search method (by phone number). It also distinguishes from siblings by focusing on phone-based lookup rather than name-based search or other country-specific 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 description provides clear context for when to use this tool: for finding Danish companies using phone numbers. It mentions '+45 prefix auto-removed' which helps users understand formatting requirements. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: the 2000-item limit, the return structure (summaries and not_found entries), and efficiency comparison. No contradiction with annotations.
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?
Two sentences, zero waste. First sentence states purpose and constraint, second provides efficiency rationale. Perfectly front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has rich annotations (readOnly, openWorld, idempotent), 100% schema coverage, and an output schema exists, the description provides excellent contextual completeness. It covers key behavioral aspects (batch limit, return structure, efficiency) without needing to explain basic safety or return values.
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 the single parameter 'org_numbers' well-documented in the schema. The description adds minimal parameter semantics beyond the schema, only implying these are Norwegian organization numbers through context. Baseline 3 is appropriate given 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 specific action ('Look up multiple companies at once'), resource ('companies'), and scope ('Norwegian' implied by tool name and sibling context). It distinguishes from sibling 'norway_get_company' by emphasizing batch capability and efficiency.
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 for when to use this tool ('More efficient than individual lookups') and mentions a practical constraint ('max 2000 org numbers'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, and idempotent behavior, so the description adds valuable context beyond these: it specifies the CVR format handling ('DK prefix auto-removed') and the effect of the 'full' parameter on returned data ('complete data with production units and owners'). This enhances understanding of tool behavior without contradicting annotations.
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 front-loaded with the core purpose and efficiently structured in two sentences: the first covers the action and primary parameter, the second explains the optional parameter's effect. Every sentence adds value without redundancy, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters), rich annotations (read-only, open-world, idempotent), and the presence of an output schema, the description is complete: it covers the key operational details (CVR handling, full parameter effect) without needing to explain return values or safety aspects already covered by structured data. It adequately supports agent decision-making.
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?
With schema description coverage at 50% (only 'cvr' has a description, 'full' does not), the description compensates well: it explains the 'cvr' parameter's format ('8-digit CVR number, DK prefix auto-removed') and the 'full' parameter's impact ('full=true for complete data with production units and owners'), adding meaningful semantics beyond the minimal schema. This addresses the coverage gap effectively.
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 specific action ('Get company'), resource ('by 8-digit CVR number'), and scope ('DK prefix auto-removed'), distinguishing it from sibling tools like denmark_search_companies which searches rather than retrieves by specific identifier. It explicitly mentions the return behavior ('Returns summary by default; full=true for complete data'), providing precise operational context.
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 for when to use this tool ('Get company by 8-digit CVR number') and implies when not to use it (e.g., not for searching by phone or production units, which are covered by siblings like denmark_search_by_phone). However, it doesn't explicitly name alternatives or state exclusions, such as when to use denmark_get_by_pnumber instead for P-number lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it warns about the API limitation (returns only one result), explains that large companies may have multiple legal entities, and suggests query variations. While annotations cover read-only, open-world, and idempotent properties, the description provides practical usage insights that aren't captured in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted words: it states the purpose upfront, provides critical warnings and limitations, offers practical usage tips, and directs to alternatives. Every sentence serves a clear purpose in helping the agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with API limitations), rich annotations, and the presence of an output schema, the description provides complete contextual information. It covers purpose, limitations, usage strategies, and alternative tools, making it fully adequate for agent decision-making.
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?
With 100% schema description coverage, the input schema already documents the single 'query' parameter as required. The description adds some semantic context by explaining what the query should contain (company name variations) and why, but doesn't provide additional parameter details beyond what's in the schema.
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 specific action ('Search Danish companies by name') and resource ('Danish companies'), distinguishing it from sibling tools like 'denmark_get_company' (which uses CVR numbers) and other country-specific search tools. It provides precise differentiation beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (search by name) versus alternatives ('If you have an 8-digit CVR number, use denmark_get_company instead'), and provides guidance on query variations to improve results. It clearly defines the tool's scope and limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context about the two response modes (compact vs. full) and what 'full' includes (addresses, industry codes, capital info), which goes beyond the annotations. No contradiction with annotations.
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?
Two sentences, front-loaded with core purpose, followed by parameter guidance. Every word earns its place with zero waste. Efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, comprehensive annotations (readOnly, openWorld, idempotent), and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, parameter effects, and response modes without redundancy.
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?
With 50% schema description coverage (only 'org_number' has description), the description compensates by explaining the 'full' parameter's effect on response format. It adds meaning beyond the schema by clarifying what 'full=true' provides, though it doesn't detail the 'org_number' format beyond '9-digit'.
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 specific action ('Get company details'), target resource ('by 9-digit org number'), and distinguishes from siblings by focusing on Norwegian companies (unlike Denmark/Finland tools) and individual lookup (vs. batch/search tools). It provides a complete verb+resource+scope statement.
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 about when to use the 'full' parameter for complete data, but doesn't explicitly state when to use this tool vs. alternatives like 'norway_batch_get_companies' or 'norway_search_companies'. It distinguishes from sibling tools by country focus but lacks explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by specifying what data is returned ('person names, birth dates, resignation status'). While annotations already provide readOnlyHint, openWorldHint, and idempotentHint, the description enhances understanding of the tool's output behavior without contradicting the annotations.
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 with just two sentences that are front-loaded with essential information. Every word serves a clear purpose, providing maximum utility with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint) and an output schema, the description provides complete context for this read-only lookup tool. It clearly states purpose, usage guidelines, and return data, making it fully adequate for the tool's 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?
With 100% schema description coverage, the input schema fully documents the single required parameter 'org_number'. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline expectation without additional value.
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 specific action ('Get board members, CEO, auditors, and other roles') and resource ('for a Norwegian company'), with explicit differentiation from sibling tool 'norway_get_signature_rights' for signature authority. This provides a precise verb+resource combination that distinguishes it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for board members, CEO, auditors, and other roles') and when to use an alternative ('For signature authority only, use norway_get_signature_rights'). This provides clear guidance on tool selection versus the named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a read-only, open-world, idempotent operation. The description adds useful context by specifying the scope of data retrieved (signature rights and prokura holders) and its limitations compared to other tools, which enhances behavioral understanding without contradicting annotations.
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, consisting of only two sentences that efficiently convey the tool's purpose and usage guidelines without any wasted words. Every sentence adds clear value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), high schema coverage, rich annotations, and the presence of an output schema, the description is complete. It adequately explains what the tool does and when to use it, with no need to detail return values or parameters.
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% description coverage, with the single parameter 'org_number' documented as 'required'. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 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 purpose with specific verbs ('Get who can sign') and resources ('signaturrett and prokura holders'), and explicitly distinguishes it from its sibling tool ('norway_get_roles') by specifying what it does not cover ('full board/role list'). This provides precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by stating when to use this tool (for signature rights and prokura holders) and when to use an alternative ('norway_get_roles' for full board/role list). This gives clear context and exclusions, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds context about the tool's scope (specific vs. all branches), which is useful behavioral information beyond annotations, though it doesn't detail rate limits or auth needs.
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 two sentences with zero waste: the first states the purpose, the second provides usage guidance. It is front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), high schema coverage (100%), rich annotations (readOnly, openWorld, idempotent), and presence of an output schema, the description is complete enough. It covers purpose and usage without needing to explain parameters or return values.
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 the single parameter 'org_number' documented as 'required'. The description adds no additional parameter details beyond what the schema provides, so it 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get details') and resource ('specific sub-unit (branch office) by its org number'), distinguishing it from the sibling tool 'norway_get_subunits' which is for listing all branches. This provides precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for a specific sub-unit') and when to use an alternative ('For listing all branches of a parent, use norway_get_subunits'), providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds useful context about scope ('all branches') and clarifies it's for parent companies, which complements the annotations without contradiction.
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 front-loaded with the core purpose, followed by usage guidelines and alternatives in three concise sentences, with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage), rich annotations (readOnly, openWorld, idempotent), and the presence of an output schema, the description is complete—it covers purpose, usage, and sibling differentiation without needing to explain parameters or return values.
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 the parameter 'parent_org_number' documented as required. The description adds no additional parameter details beyond what the schema provides, so it 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all branches') and resource ('of a parent company by its org number'), distinguishing it from sibling tools like norway_get_subunit (for specific branches) and norway_search_subunits (for name-based searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool ('what branches does X have?', 'list sub-units') and when not to use it, with clear alternatives named (norway_get_subunit for specific branches, norway_search_subunits for name searches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide: it discloses that results are 'Not cached' (indicating fresh data) and specifies the temporal nature of the query ('since a timestamp'). While annotations already indicate read-only, open-world, and idempotent characteristics, the description provides additional operational context without contradicting annotations.
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 with just two sentences that each serve distinct purposes: the first defines the tool's function and key characteristics, the second provides sibling differentiation. There is zero wasted language, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's read-only nature (confirmed by annotations), the presence of an output schema, and the clear sibling differentiation, the description provides complete contextual information. It covers purpose, usage guidelines, and key behavioral traits while avoiding redundancy with structured fields.
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?
With 50% schema description coverage (only 'since' has a description), the description doesn't provide additional parameter details beyond what's implied by 'since a timestamp' for the 'since' parameter. It doesn't explain the 'size' parameter at all. The description adds minimal value over the schema, meeting the baseline expectation when schema coverage is incomplete.
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 specific action ('Get sub-unit (branch) registry changes'), resource ('sub-unit (branch) registry'), and temporal scope ('since a timestamp'). It explicitly distinguishes this tool from its sibling 'norway_get_updates' by specifying it's for sub-units rather than main companies, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('For main company updates, use norway_get_updates instead'), creating a clear alternative scenario. It also specifies the temporal context ('since a timestamp') and notes the data freshness ('Not cached'), giving comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by stating 'Not cached' (performance characteristic) and specifying the timestamp format requirement ('ISO 8601'). While annotations cover read-only, open-world, and idempotent properties, the description provides additional operational details that enhance understanding.
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 efficient with three focused sentences: purpose statement, usage guidelines, and sibling differentiation. Every sentence adds essential information with zero wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint), and the presence of an output schema, the description provides complete contextual information. It covers purpose, usage scenarios, exclusions, and behavioral characteristics adequately.
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?
With 50% schema description coverage (only 'since' parameter has a description), the description doesn't explicitly explain parameter semantics. However, it implies the 'since' parameter's purpose through context ('since a timestamp'), providing marginal value beyond the schema's minimal documentation.
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 specific action ('monitor main company registry changes') and resource ('main company registry'), and explicitly distinguishes it from its sibling tool 'norway_get_subunit_updates' for branch office changes. This provides precise differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'USE WHEN' examples ('what companies changed recently?', 'registry updates') and provides clear exclusion guidance ('For branch office changes only, use norway_get_subunit_updates'). This gives comprehensive when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior, covering safety and reliability. The description adds valuable context beyond annotations by specifying the 24-hour cache duration, which is a key behavioral trait not captured in structured fields. No contradictions with annotations exist.
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 front-loads the core purpose and includes essential details (examples, cache) without redundancy. Every word contributes to understanding, and there is no wasted text or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, annotations covering key behaviors, and an output schema present), the description is complete. It explains what the tool does, provides examples, and adds cache information, which is sufficient for an agent to understand and invoke it correctly without needing to detail return values (handled by output schema).
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing instead on the tool's function and cache behavior. It adds semantic value by explaining what data is returned (codes with descriptions), compensating for the lack of parameter details.
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 specific action ('Get'), resource ('organization form codes'), and scope ('Norwegian' implied by tool name and context), distinguishing it from sibling tools that focus on companies, subunits, or other entities. It provides concrete examples (AS, ENK, NUF) and mentions descriptions, making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests usage for retrieving cached organization form codes, but does not explicitly state when to use this tool versus alternatives (e.g., vs. other country-specific tools or general company lookups). It mentions the 24-hour cache, which provides some context, but lacks explicit guidance on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, open-world, idempotent operation. The description adds valuable context by specifying the search is by name and listing filter options, which enhances understanding beyond the annotations. No contradictions with annotations are present.
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 front-loaded with the core purpose, followed by usage guidance and filter details in a single, efficient sentence. Every element serves a clear purpose without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters), low schema coverage, and the presence of an output schema, the description is complete enough. It covers purpose, usage guidelines, and key parameters, and the output schema handles return values, so no additional explanation is needed.
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 low at 13%, with only the 'query' parameter documented. The description mentions filter parameters like 'org_form', 'municipality', etc., but doesn't provide detailed semantics or examples. It adds some meaning but doesn't fully compensate for the schema gaps, aligning with the baseline for partial 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 specific action ('Search Norwegian companies by name') and resource ('Norwegian companies'), distinguishing it from sibling tools like 'norway_get_company' which requires an org number. It explicitly differentiates from that sibling, making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'If you have a 9-digit org number, use norway_get_company instead.' It also lists available filters, helping users understand the tool's scope and when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it discloses the 20-result max per page limitation and the 900+ result potential for common names. Annotations already cover read-only, open-world, and idempotent characteristics, so the description appropriately supplements with practical constraints without contradiction.
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 efficiently structured with zero waste: first sentence states purpose, second gives key constraints, third offers narrowing strategies, fourth provides alternative tool guidance. Every sentence earns its place and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, low schema coverage (20%), and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, constraints, usage strategies, and alternatives - providing all necessary context for an agent to use the tool effectively without needing to explain return format details.
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?
With only 20% schema description coverage (only 'query' has a description), the description compensates well by explaining the purpose of 'company_form' (OY/OYJ for main companies) and 'location' (city filtering), and implies 'query' usage strategies. It doesn't cover 'page' or 'size' parameters, but adds meaningful context for the most critical 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 specific action ('Search Finnish companies by name'), identifies the resource ('Finnish companies'), and distinguishes it from siblings by explicitly mentioning 'finland_get_company' as an alternative for Y-tunnus searches. It goes beyond just restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: 'If you have a Y-tunnus, use finland_get_company instead.' It also offers specific narrowing strategies (company_form, location, exact name) and warns about common names returning many results, giving clear context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context about the search scope (by name, with municipality filtering) and clarifies the prerequisite condition (not having parent org number), which goes beyond what annotations provide. No contradiction with annotations exists.
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 efficiently structured with two sentences: the first states the purpose and key parameters, the second provides usage guidelines and sibling differentiation. Every sentence adds value with zero wasted words, making it highly concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 1 required), the presence of comprehensive annotations, and an output schema (which handles return values), the description provides complete context. It covers purpose, usage guidelines, key parameters, and sibling differentiation, leaving no significant gaps for agent understanding.
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?
Schema description coverage is only 25% (only the 'query' parameter has a description), but the description compensates by explaining that 'query' is for searching by name and mentions the 'municipality' parameter for filtering. However, it doesn't address 'page' and 'size' parameters, leaving some gaps in parameter understanding.
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 specific action ('Search Norwegian branch offices by name') and resource ('branch offices'), and explicitly distinguishes it from its sibling tool 'norway_get_subunits' by specifying different use cases. This provides excellent differentiation and clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('find branches named X and you don't have the parent org number') and when to use an alternative ('For listing all branches of a known parent, use norway_get_subunits'). It also mentions the municipality filter capability, giving clear context for application.
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:

[![nordic-registry-mcp-server MCP server](https://glama.ai/mcp/servers/olgasafonova/nordic-registry-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/olgasafonova/nordic-registry-mcp-server)

Score Badge

Copy to your README.md:

[![nordic-registry-mcp-server MCP server](https://glama.ai/mcp/servers/olgasafonova/nordic-registry-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/olgasafonova/nordic-registry-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/olgasafonova/nordic-registry-mcp-server'

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