Query official Nordic company registries to verify company legitimacy, check financials, board members, signing rights, and more across Norway, Denmark, Finland, and Sweden.
Norway (Brønnøysundregistrene) — 12 tools:
Search companies by name with filters for org form (AS/ENK/NUF), municipality, VAT status, and bankruptcy status
Get company details by 9-digit org number (status, address, employees, industry, capital, etc.)
Get roles — board members, CEO, auditors with names, birth dates, and resignation status
Get signature rights — who can legally sign (signaturrett) and prokura holders
Batch lookup — up to 2,000 companies at once by org number
Branch offices — list all subunits, get a specific subunit, or search subunits by name
Monitor updates — recent changes to main company or branch office registries since a given timestamp
Reference data — municipality codes and organization form codes
Denmark (CVR) — 5 tools:
Search companies by name (returns single best match)
Get company details by 8-digit CVR number; optional full mode includes production units and owners
List production units (P-numbers) with pagination
Search by phone number — find a company by its registered phone
Get by P-number — look up the parent company of a production unit
Finland (PRH) — 2 tools:
Search companies by name with optional filters for company form (OY/OYJ) and location, paginated
Get company details by Y-tunnus; optional full mode includes previous names and registry entries
Sweden — 4 tools (OAuth2 required):
Get company details by Swedish org number
List annual reports (årsredovisningar) for a company
Download a specific annual report document
Check API connectivity status
Verify company legitimacy across Norway, Denmark, Finland, and Sweden in seconds. Check bankruptcy status, board members, signing authority, and financial data from official registries, without switching between four government websites.
23 tools wrapping the public APIs of Brønnøysundregistrene, CVR, PRH, and Bolagsverket. Works with Claude Desktop, Claude Code, Cursor, and any MCP client.
What it does:
Search companies by name across four Nordic countries
Get company details: status, employees, industry, addresses
Look up board members, CEOs, auditors, and roles
Check who can legally sign on behalf of a company
Access Swedish annual reports (årsredovisningar)
Batch lookups for validating lists of company IDs
What it doesn't do:
Modify registry data (read-only)
Store or cache personal data beyond the session
Require payment (all underlying APIs are free)
Related MCP server: Firmaradar
Country | Registry | Tools | ID Format |
Norway | 12 | 9 digits (e.g., | |
Denmark | 5 | 8 digits (e.g., | |
Finland | 2 | 7+1 digits (e.g., | |
Sweden | 4 | 10 digits (e.g., |
All APIs are free. Norway, Denmark, and Finland require no authentication. Sweden uses the värdefulla datamängder API which requires OAuth2 credentials (free registration).
Once connected, just ask your AI:
You say... | What happens |
"Find Norwegian companies named Equinor" | Searches Brønnøysundregistrene |
"Get details for org number 923609016" | Returns full company info |
"Who is on the board of 923609016?" | Lists board members, CEO, roles |
"Find Danish company Novo Nordisk" | Searches CVR registry |
"Look up Finnish company Nokia" | Searches PRH registry |
"Get company 0112038-9 from Finland" | Returns Nokia's full details |
"Get Swedish company 5560125790" | Returns company info from Bolagsverket |
"List annual reports for Swedish company X" | Lists available årsredovisningar |
When processing permit applications, license renewals, or grant requests, verify the applying company exists and is in good standing.
You: "A company applied for an environmental permit. Org number 923609016.
Check if they're active and who can sign on their behalf."
AI: Let me verify the company and check signing authority.
→ norway_get_company("923609016")
→ norway_get_signature_rights("923609016")
Result: Equinor ASA - Active since 1972, registered for VAT, 21,200 employees.
Authorized signatories: [Name 1] (CEO), [Name 2] + [Name 3] (joint signature).
The application signature matches an authorized signatory.Before awarding a municipal contract, verify that bidding companies are legitimate and not bankrupt.
You: "We received bids from three Danish companies for the IT contract.
CVR numbers: 10150817, 25063783, 37553472. Are they all legitimate?"
AI: I'll verify each company's status.
→ denmark_get_company("10150817")
→ denmark_get_company("25063783")
→ denmark_get_company("37553472")
Result:
- 10150817: Novo Nordisk A/S - Active, 47,000+ employees ✓
- 25063783: Mærsk A/S - Active, established company ✓
- 37553472: [Company name] - BANKRUPT ✗
Recommendation: Exclude 37553472 from consideration.When processing grant applications from voluntary organizations, verify their registration in Frivillighetsregisteret.
You: "An organization applied for cultural funding.
They claim to be a registered non-profit. Org number 971274808."
AI: Let me check their voluntary organization status.
→ norway_get_company("971274808")
Result: Norges Røde Kors - Registered in Frivillighetsregisteret since 2009.
Organization form: FLI (Forening/lag/innretning).
Activity: Humanitarian aid and emergency response.
Confirmed as eligible non-profit organization.Track new company registrations or status changes in regulated sectors.
You: "I need to monitor new companies in the financial sector.
What relevant registrations happened this week?"
AI: Let me check recent registry updates.
→ norway_get_updates(since="2024-01-08T00:00:00Z", size=100)
Result: 12 new registrations in financial services sector:
- 3 new AS companies (aksjeselskap)
- 2 new NUF branches of foreign financial institutions
- 7 updates to existing financial companies
[List with org numbers for follow-up]When coordinating with other Nordic authorities, identify a company's presence across jurisdictions.
You: "We're investigating a company that may operate across Nordic countries.
Check if Volvo has registered entities in Norway and Denmark."
AI: Let me search both registries.
→ norway_search_companies("Volvo")
→ denmark_search_companies("Volvo")
Result: Found registered entities:
- Norway: Volvo Norge AS (org 923609016) - 450 employees, automotive
- Denmark: Volvo Danmark A/S (CVR 12345678) - 320 employees
Both are subsidiaries of Swedish parent company.When receiving bulk data submissions referencing company identifiers, validate them against official registries.
You: "A ministry submitted a list of 50 org numbers for a new subsidy program.
Validate which ones are current and active."
AI: I'll validate them against Brønnøysundregistrene.
→ norway_batch_get_companies([list of 50 org numbers])
Result:
- 47 companies: Active and valid ✓
- 2 companies: Marked as bankrupt - may need review
- 1 org number: Not found in registry - possibly incorrect
Flagged entries exported for manual review.Support policy analysis by examining business composition in specific areas.
You: "How many AS companies are registered in Oslo municipality?"
AI: Let me search with municipality filter.
→ norway_search_companies(query="*", org_form="AS", municipality="0301")
Result: Found 45,231 AS companies registered in Oslo (municipality 0301).
Paginated results available for detailed analysis.Before approving state aid or contracts above threshold, verify company governance.
You: "Check the board composition of company 914778271.
We need this for the state aid application review."
AI: Let me retrieve their roles.
→ norway_get_company("914778271")
→ norway_get_roles("914778271")
Result: [Company name] - AS registered 2015
Board members:
- [Name 1] - Styreleder (Chair)
- [Name 2] - Styremedlem
- [Name 3] - Styremedlem
- [Name 4] - Daglig leder (CEO)
Auditor: [Audit firm name]When reviewing Swedish companies for cross-border matters, check available financial documentation.
You: "A Swedish company applied for recognition in Norway.
What financial reports are available for org 5560125790?"
AI: Let me check Bolagsverket for filed documents.
→ sweden_get_company("5560125790")
→ sweden_get_document_list("5560125790")
Result: [Company name] - Active Swedish AB
Available årsredovisningar: 8 annual reports (2016-2023)
Most recent: Financial year ending 2023-06-30, filed 2023-08-15.Go to Releases and download for your platform.
git clone https://github.com/olgasafonova/nordic-registry-mcp-server.git
cd nordic-registry-mcp-server
go build .Requires Go 1.24+
/add-plugin nordic-registryclaude mcp add nordic-registry ./nordic-registry-mcp-serverAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"nordic-registry": {
"command": "/path/to/nordic-registry-mcp-server"
}
}
}Restart Claude Desktop after changes.
Not working? Tell us what made it hard — even one sentence helps.
Tool | Description |
| Search companies by name |
| Get company details by org number |
| Get board members, CEO, auditors |
| Get signature rights and prokura |
| Look up multiple companies at once |
| List branch offices for a company |
| Get specific branch office details |
| Search branch offices by name |
| Get recent registry changes |
| Get recent branch office changes |
| List municipality codes |
| List organization form codes (AS, ENK, etc.) |
Tool | Description |
| Search companies by name (returns single best match) |
| Get company details by CVR number |
| List production units (P-numbers), paginated |
| Find company by phone number |
| Get company by P-number |
Note: Danish search returns only one result. Large companies often have multiple entities. Try variations like "[Company] Denmark", "[Company] A/S", or pre-merger names if the first result seems wrong.
Tool | Description |
| Search companies by name (paginated, use filters for broad queries) |
| Get company details by business ID |
Note: Common names like "Nokia" return 900+ results. Use exact legal name ("Nokia Oyj"), filter by
company_form(OY/OYJ), or filter bylocationto narrow results.
Requires OAuth2 credentials. Set BOLAGSVERKET_CLIENT_ID and BOLAGSVERKET_CLIENT_SECRET environment variables.
Tool | Description |
| Get company details by organization number |
| List annual reports (årsredovisningar) |
| Download annual report by document ID |
| Check API availability and OAuth2 status |
Note: Sweden has no name search in this API - you must have the org number.
"Find Norwegian companies named Telenor"
"Search for AS companies in Oslo"
"Find Danish companies named Carlsberg"
"Look up Finnish company Kone"
"Find voluntary organizations named Røde Kors"
"Get details for Norwegian org 923609016"
"Look up CVR 10150817"
"Get Finnish company 0112038-9"
"Who is on the board of 923609016?"
"Find the CEO of Equinor"
"List all directors for org 914778271"
"Who can sign for company 923609016?"
"Get signature rights for Equinor"
"Who has prokura for 914778271?"
"What branches does 923609016 have?"
"Search for branch offices named Equinor"
"List production units for CVR 10150817"
"What companies changed since yesterday?"
"Get recent registry updates"
"What branch offices changed recently?"
"Look up these companies: 923609016, 914778271, 985399077"
"Validate these org numbers from my spreadsheet"
"Get details for multiple Norwegian companies at once"
"List all Norwegian municipalities"
"What is Oslo's municipality code?"
"What does AS mean?"
"List organization form codes"
"Find company with phone 33121212"
"Look up production unit P-number 1234567890"
"Get Swedish company 5560125790"
"Look up Volvo's organization number in Sweden"
"What annual reports are available for 5560125790?"
"List årsredovisningar for Swedish company X"
"Is the Swedish API working?"
Sweden's Bolagsverket API requires OAuth2 authentication (free).
Register for the värdefulla datamängder API (submit customer registration form)
Access the Developer Portal to get your OAuth2 credentials
Set environment variables:
export BOLAGSVERKET_CLIENT_ID="your-client-id"
export BOLAGSVERKET_CLIENT_SECRET="your-client-secret"The server will log whether Sweden credentials are configured on startup. If not configured, Sweden tools are simply not registered.
For remote access or integration with other tools:
# Start HTTP server
./nordic-registry-mcp-server -http :8080
# With authentication
./nordic-registry-mcp-server -http :8080 -token "your-secret-token"
# Full production setup
./nordic-registry-mcp-server -http :8080 \
-token "your-secret-token" \
-origins "https://app.example.com" \
-rate-limit 60 \
-trusted-proxies "10.0.0.0/8"Bearer Token Auth: Optional authentication via -token flag or MCP_AUTH_TOKEN env var. Binding to a non-loopback address without a token is refused at startup; loopback binds (127.0.0.1, localhost) still run token-free for local development.
CORS Protection: Restrict origins via -origins flag (comma-separated)
Rate Limiting: Per-IP rate limiting via -rate-limit (requests per minute)
Trusted Proxies: Honor X-Forwarded-For from trusted networks via -trusted-proxies
Request Size Limits: 2MB default, 10MB max request body
Every endpoint except the /health and /ready probes shares the same auth path: when a token is set, /, /metrics, /status, and /tools all require it. The probes stay unauthenticated so orchestrators can reach them.
Endpoint | Description | Auth |
| MCP protocol (Streamable HTTP) | Required when token set |
| Liveness check | Public |
| Readiness check (verifies API connectivity) | Public |
| List all tools by country | Required when token set |
| Circuit breaker stats | Required when token set |
| Prometheus metrics | Required when token set |
nordic-registry-mcp-server/
├── main.go # Entry point, HTTP/stdio transport, security middleware
├── internal/
│ ├── base/ # Shared HTTP client with resilience
│ │ └── client.go # Connection pooling, retries, rate limiting
│ ├── errors/ # Shared error types
│ │ └── errors.go # NotFoundError, ValidationError
│ ├── infra/ # Resilience infrastructure
│ │ ├── cache.go # LRU cache with TTL
│ │ └── resilience.go # Circuit breaker, request deduplication
│ ├── norway/ # Norwegian registry (Brønnøysundregistrene)
│ ├── denmark/ # Danish registry (CVR)
│ ├── finland/ # Finnish registry (PRH)
│ └── sweden/ # Swedish registry (Bolagsverket, OAuth2)
├── tools/
│ ├── definitions.go # Tool specifications (23 tools)
│ ├── handlers.go # MCP tool registration
│ └── registry.go # Tool metadata types
├── metrics/ # Prometheus metrics (namespace: nordic_registry_mcp)
└── tracing/ # OpenTelemetry tracingLRU Cache: TTL varies by endpoint type (searches: 2min, details: 5-15min, documents: 30min, reference data: 24h)
Circuit Breaker: Opens after 5 consecutive failures, 30s recovery timeout
Request Deduplication: Identical concurrent requests share a single API call
Rate Limiting: Semaphore-based concurrency control (15 concurrent requests)
Retry with Backoff: Exponential backoff with jitter on transient failures
Response Size Limits: 10MB for API responses, 100MB for document downloads
Token Efficiency: Paginated responses (default 20 results) to minimize LLM context usage
Document | Description |
Installation, configuration, and troubleshooting | |
Complete reference for all 23 tools with parameters, return values, and examples | |
System design, request flow, resilience patterns | |
Linux containers, Docker, Kubernetes, monitoring |
# Build
go build .
# Test
go test ./...
# Lint (requires golangci-lint)
golangci-lint runThis server is designed to work alongside public360-mcp-server, which provides AI access to Public 360° document and case management systems used by Nordic public sector organizations.
The integration scenario:
A caseworker receives a permit application from a company. Today's workflow:
Open the case in Public 360°
Manually look up the company in Brønnøysundregistrene
Verify the company is active and not bankrupt
Check if the signer has authority
Copy relevant details back into the case
With both MCP servers connected:
You: "I received permit application case 2024/12345.
The applicant is org 923609016. Verify the company
and check if the signature is valid."
AI: [Calls public360: sif_get_cases to get case details]
[Calls nordic-registry: norway_get_company to verify company]
[Calls nordic-registry: norway_get_signature_rights to check authority]
Result: Case 2024/12345 - Environmental permit application
Applicant: Equinor ASA (923609016) - ACTIVE
Signed by: [Name] - Authorized signatory ✓
Recommendation: Signature is valid. Company is in good standing.Planned integration points:
Nordic Registry | Public 360° | Use Case |
|
| Sync company data to contacts |
|
| Import board members as contacts |
|
| Auto-populate case with verified company info |
|
| Attach annual reports to cases |
This turns two separate data sources into a connected workflow where the AI can verify external data and update internal systems in one conversation.
The current implementation uses free, open APIs. More comprehensive data is available through premium services:
Sweden (Bolagsverket)
Current (Free) | Premium Potential |
Basic company info | Board members and roles |
Annual reports (årsredovisningar) | Authorized signatories (firmatecknare) |
Company status | Company mortgages (företagsinteckningar) |
Real-time updates (not daily batch) | |
Historical board changes |
The free värdefulla datamängder API we use today provides company basics and annual reports. Bolagsverket offers additional e-services for authorized signatories and company mortgages. Third-party aggregators like Roaring.io provide enriched datasets combining multiple sources.
Finland (PRH)
Current (Free) | Virre Service |
Basic company details | Board members and managing directors |
Digital financial statements (IXBRL) | Authorized signatories |
Registration notifications | Procuration holders |
Non-digital financial statements | |
Translated Trade Register extracts | |
Articles of association |
The free PRH Open Data API provides basic company information updated daily. The Virre Information Service offers board member details, signatory information, and document purchases. Contract clients get reduced fees for high-volume access.
Why this matters:
Norway already provides board members, roles, and signature authority through the free Brønnøysundregistrene API. Adding premium Sweden and Finland data would give consistent coverage across all four countries for:
Verifying who can sign contracts
Checking board composition for due diligence
Accessing complete financial documentation
Check out my other MCP servers:
Server | Description | Stars |
Access GLEIF LEI database. Look up company identities, verify legal entities. | ||
Connect AI to any MediaWiki wiki. Search, read, edit wiki content. | ||
Control Miro whiteboards with AI. Boards, diagrams, mindmaps, and more. | ||
Talk to your ProductPlan roadmaps. Query OKRs, ideas, launches. | ||
Nordic grocery deal hunting. Find offers, plan meals, track spending. |
Apache License 2.0
Built with Go MCP SDK
Data from Brønnøysundregistrene, CVR, PRH, Bolagsverket
Get parent company for a production unit P-number. Returns the owning company's details.
| Name | Required | Description | Default |
|---|---|---|---|
| p_number | Yes | required |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| company | No | |
| message | No |
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.
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.
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.
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.
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.
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.
Get company by 8-digit CVR number. DK prefix auto-removed. Returns summary by default; full=true for complete data with production units and owners.
| Name | Required | Description | Default |
|---|---|---|---|
| cvr | Yes | required | |
| full | No |
| Name | Required | Description |
|---|---|---|
| company | No | |
| summary | No |
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.
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.
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.
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.
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.
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.
Get production units (P-numbers) for a Danish company by CVR. Paginated: 20 results per page by default (max 100). Use page parameter for more results.
| Name | Required | Description | Default |
|---|---|---|---|
| cvr | Yes | required | |
| page | No | ||
| size | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| size | Yes | |
| has_more | Yes | |
| total_pages | Yes | |
| total_results | Yes | |
| production_units | Yes |
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.
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.
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.
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.
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.
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.
Find Danish company by phone number. +45 prefix auto-removed. Not all companies have registered phones.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | required |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| company | No | |
| message | No |
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.
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.
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.
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.
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.
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.
Search Danish companies by name. WARNING: Returns only ONE result (CVR API limitation). Large companies often have multiple legal entities. Try variations: "[Company] Denmark", "[Company] A/S", "[Company] DK", "[Company] Holding", or pre-merger names. If you have an 8-digit CVR number, use denmark_get_company instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | required |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| company | No | |
| message | No |
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.
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.
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.
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.
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.
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.
Get company by Y-tunnus (e.g., 0112038-9). FI prefix auto-removed. Returns summary by default; full=true for complete data with previous names and registry entries.
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | required | |
| full | No |
| Name | Required | Description |
|---|---|---|
| company | No | |
| summary | No |
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.
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.
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.
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.
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.
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.
Search Finnish companies by name. Returns max 20 results per page. Common names return 900+ results. To narrow: use company_form=OY/OYJ for main companies, add location for city, or search exact name "Nokia Oyj" instead of "Nokia". If you have a Y-tunnus, use finland_get_company instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | required | |
| location | No | ||
| company_form | No | ||
| page | No | ||
| size | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| size | Yes | |
| has_more | Yes | |
| companies | Yes | |
| total_results | Yes |
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.
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.
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.
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.
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.
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.
Look up multiple companies at once (max 2000 org numbers). Returns company summaries and list of not_found entries. More efficient than individual lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| org_numbers | Yes | required |
| Name | Required | Description |
|---|---|---|
| companies | Yes | |
| not_found | No | |
| total_results | Yes |
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.
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.
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.
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.
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.
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.
Get company details by 9-digit org number. Returns compact summary by default; set full=true for complete data including all addresses, industry codes, and capital info.
| Name | Required | Description | Default |
|---|---|---|---|
| org_number | Yes | required | |
| full | No |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| company | No | |
| message | No | |
| summary | No |
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.
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.
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.
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.
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.
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.
Get board members, CEO, auditors, and other roles for a Norwegian company. Returns person names, birth dates, resignation status. For signature authority only, use norway_get_signature_rights.
| Name | Required | Description | Default |
|---|---|---|---|
| org_number | Yes | required |
| Name | Required | Description |
|---|---|---|
| role_groups | Yes |
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.
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.
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.
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.
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.
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.
Get who can sign for a company (signaturrett) and prokura holders. For full board/role list, use norway_get_roles instead.
| Name | Required | Description | Default |
|---|---|---|---|
| org_number | Yes | required |
| Name | Required | Description |
|---|---|---|
| prokura | Yes | |
| summary | Yes | |
| company_name | No | |
| signature_rights | Yes | |
| organization_number | Yes |
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.
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.
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.
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.
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.
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.
Get details for a specific sub-unit (branch office) by its org number. For listing all branches of a parent, use norway_get_subunits.
| Name | Required | Description | Default |
|---|---|---|---|
| org_number | Yes | required |
| Name | Required | Description |
|---|---|---|
| sub_unit | Yes |
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.
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.
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.
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.
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.
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.
List all branches of a parent company by its org number. USE WHEN: "what branches does X have?", "list sub-units". For one specific branch by its own org number, use norway_get_subunit. To search branches by name, use norway_search_subunits.
| Name | Required | Description | Default |
|---|---|---|---|
| parent_org_number | Yes | required |
| Name | Required | Description |
|---|---|---|
| sub_units | Yes | |
| total_results | Yes |
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.
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.
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.
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.
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.
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.
Get sub-unit (branch) registry changes since a timestamp. Not cached. For main company updates, use norway_get_updates.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | required | |
| size | No |
| Name | Required | Description |
|---|---|---|
| updates | Yes |
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.
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.
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.
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.
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.
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.
Monitor main company registry changes since a timestamp (ISO 8601). USE WHEN: "what companies changed recently?", "registry updates". Not cached. For branch office changes only, use norway_get_subunit_updates.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | required | |
| size | No |
| Name | Required | Description |
|---|---|---|
| updates | Yes |
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.
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.
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.
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.
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.
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.
Get Norwegian municipality codes for filtering searches. Cached 24h. Example: Oslo = 0301.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| municipalities | Yes |
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.
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.
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.
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.
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.
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.
Get organization form codes (AS=limited, ENK=sole prop, NUF=foreign branch, etc.) with descriptions. Cached 24h.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| org_forms | Yes |
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.
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.
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.
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.
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.
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.
Search Norwegian companies by name. If you have a 9-digit org number, use norway_get_company instead. Filters: org_form (AS/ENK/NUF), municipality, registered_in_vat, bankrupt, registered_in_voluntary.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | required | |
| page | No | ||
| size | No | ||
| org_form | No | ||
| municipality | No | ||
| registered_in_vat | No | ||
| bankrupt | No | ||
| registered_in_voluntary | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| companies | Yes | |
| total_pages | Yes | |
| total_results | Yes |
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.
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.
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.
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.
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.
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.
Search Norwegian branch offices by name. USE WHEN: "find branches named X" and you don't have the parent org number. Filter by municipality. For listing all branches of a known parent, use norway_get_subunits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | required | |
| page | No | ||
| size | No | ||
| municipality | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| sub_units | Yes | |
| total_pages | Yes | |
| total_results | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
denmark_get_by_pnumberdenmark_get_companydenmark_get_production_unitsdenmark_search_by_phonedenmark_search_companiesfinland_get_companyfinland_search_companiesnorway_batch_get_companiesnorway_get_companynorway_get_rolesnorway_get_signature_rightsnorway_get_subunitnorway_get_subunit_updatesnorway_get_subunitsnorway_get_updatesnorway_list_municipalitiesnorway_list_org_formsnorway_search_companiesnorway_search_subunitsThis server cannot be deployed
Scored across 19 tools
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.
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.
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.
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.
Nordic company intelligence: look up companies, AI summaries, scores and signals via MCP.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
The company registry MCP: brreg orgnr, Companies House, Bolagsverket organisationsnummer.
