How do I use Zefix MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zefix MCP Server show me company details for CHE-123.456.789" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Zefix MCP Server

by ishumilin

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

About Schwaizer

SHAPING SWITZERLAND'S AI FUTURE Empowering Swiss businesses and society through responsible AI adoption. Founded in 2025, Schwaizer is a non-profit organization dedicated to accelerating the responsible adoption of artificial intelligence across Switzerland.

Website: https://www.schwaizer.ch

Zefix MCP Server

MCP (Model Context Protocol) server providing access to Swiss Company Registry data through Zefix REST API and UID Webservice.

Features

Dual API Integration

Zefix REST API: Fast company searches and SOGC (Official Gazette) tracking
UID Webservice: Rich company data including NOGA codes, VAT details, and commercial register information

Available Tools (9 tools)

Zefix API Tools

zefix_search_companies - Search for Swiss companies using the Zefix API.
zefix_get_company_by_uid - Get detailed company information from Zefix by UID, with optional UID Webservice enrichment.
zefix_get_daily_registrations - Get all company registrations and publications from SOGC for a specific date.
zefix_get_company_publications - Get all SOGC publications for a specific company by UID.

UID Webservice Tools

uid_advanced_search - Advanced company search using the UID Webservice.
uid_validate_uid - Validate a Swiss UID.
uid_validate_vat_number - Validate a Swiss VAT number.
uid_get_company_details - Get detailed company information using only the UID Webservice.

Combined API Tools

generate_due_diligence_report - Generate a comprehensive due diligence report combining data from both Zefix and UID Webservice.

Related MCP server: bexio-mcp

Installation

npm install

Configuration

Copy .env.example to .env and configure:

# Zefix REST API Credentials (required for Zefix tools)
# Note: Credentials must be requested from Federal Registry of Commerce
ZEFIX_USERNAME=your_username
ZEFIX_PASSWORD=your_password

# UID Webservice (no auth needed for Public Services)
UID_PUBLIC_URL=https://www.uid-wse.admin.ch/V5.0/PublicServices.svc?wsdl

# Optional settings
CACHE_ENABLED=true
CACHE_TTL=3600
LOG_LEVEL=info

Usage

Running the Server

npm start

Example Tool Calls

Search for companies (Zefix)

{
  "name": "zefix_search_companies",
  "arguments": {
    "name": "Migros",
    "canton": "ZH",
    "activeOnly": true
  }
}

Get company details (Zefix + UID)

{
  "name": "zefix_get_company_by_uid",
  "arguments": {
    "uid": "CHE-123.456.789",
    "enrichWithUidData": true
  }
}

Validate UID (UID Webservice)

{
  "name": "uid_validate_uid",
  "arguments": {
    "uid": "CHE-123.456.789"
  }
}

Generate due diligence report (Zefix + UID)

{
  "name": "generate_due_diligence_report",
  "arguments": {
    "uid": "CHE-123.456.789",
    "includePublications": true
  }
}

Get daily registrations (Zefix)

{
  "name": "zefix_get_daily_registrations",
  "arguments": {
    "date": "2025-11-15"
  }
}

API Documentation

Zefix REST API

Base URL: https://www.zefix.admin.ch/ZefixPublicREST/api/v1
Authentication: Basic Auth
SOGC publications:
- Per-company publications are returned via GET /api/v1/company/uid/{uid} in the sogcPub[] field of the company payload (there is no GET /api/v1/sogc/uid/{uid} endpoint).
- Daily publications are available via GET /api/v1/sogc/bydate/{date}.

UID Webservice

Public Services URL: https://www.uid-wse.admin.ch/V5.0/PublicServices.svc?wsdl
Protocol: SOAP
Authentication: None required for Public Services

Data Sources

Zefix: Federal Commercial Register (Handelsregister)
UID Register: Federal Business and Enterprise Register
SOGC/SHAB: Swiss Official Gazette of Commerce

Caching

The server implements intelligent caching:

Search results: 30 minutes
Company details: 1 hour
SOGC data: 6 hours
UID/VAT validation: 1-24 hours
Reference data: 24 hours

Error Handling

All tools include comprehensive error handling:

Input validation with Zod schemas
API error handling with retries
Graceful fallbacks when enrichment fails
Detailed error messages in responses

Development

Project Structure

zefix-mcp-server/
├── src/
│   ├── index.js              # MCP server entry point
│   ├── config.js             # Configuration
│   ├── api/
│   │   ├── zefix-client.js   # Zefix REST client
│   │   ├── uid-client.js     # UID SOAP client
│   │   └── schemas.js        # Validation schemas
│   ├── tools/
│   │   ├── company-search.js # Search tools
│   │   ├── validation.js     # Validation tools
│   │   ├── sogc.js          # SOGC tools
│   │   └── due-diligence.js # Due diligence tool
│   └── utils/
│       ├── logger.js         # Logging
│       ├── cache.js          # Caching
│       └── formatting.js     # Formatting utilities
├── .env                      # Environment variables
├── package.json
└── README.md

Running Tests

npm test

Linting

npm run lint

Scripts

Helper scripts (for local development and manual checks):

scripts/describe-wsdl.mjs — Inspect/describe UID Webservice WSDL structure
scripts/test-uid-search.mjs — Exercise UID search endpoints with sample queries
scripts/test-uid-search-variants.mjs — Try multiple UID search variants

Run examples:

node scripts/describe-wsdl.mjs
node scripts/test-uid-search.mjs "CHE-123.456.789"
node scripts/test-uid-search-variants.mjs "Migros"

License

MIT

Support

For issues with:

Zefix API: Contact Zefix support zefix@bj.admin.ch
UID Webservice: Contact uid@bfs.admin.ch
This MCP Server: Open an issue on GitHub

Available Tools

9 tools

advanced_searchC

Advanced company search using the UID Webservice. Supports multiple filters including person names, legal forms, and canton.

ParametersJSON Schema

Name	Required	Description
`organisationName`	No	Organization name (minimum 3 characters)
`personName`	No	Search by person name (for sole proprietorships)
`canton`	No	Canton code (e.g., ZH, BE)
`legalForms`	No	Array of legal form codes to filter by
`activeOnly`	No	Only return active companies
`maxResults`	No	Maximum number of results

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as default search behavior, parameter interaction (AND/OR), authentication requirements, rate limits, or error handling. It only mentions the underlying webservice.

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 sentences, front-loaded with the core purpose. No unnecessary words.

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

Completeness2/5

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

Given the complexity (6 optional parameters, no output schema, multiple sibling search tools), the description is insufficient. It lacks explanation of search logic, result behavior, and differentiation from 'search_companies'.

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 coverage is 100%, so parameters are documented. The description repeats 'person names, legal forms, and canton' but does not add meaning beyond the schema, such as whether filters are combined or any defaults.

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 it is an advanced company search with multiple filters, but does not differentiate from the sibling tool 'search_companies'. The verb 'search' and resource 'company' are clear, but the 'advanced' aspect is not contextualized.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'search_companies' or 'get_company_by_uid'. The description merely lists supported filters without indicating use cases or prerequisites.

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

generate_due_diligence_reportB

Generate a due diligence report for a Swiss company using Zefix and UID Webservice data.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	Company UID in format CHE-XXX.XXX.XXX
`includePublications`	No	Include recent SOGC publications in report (default: true)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions using external data sources but does not state whether the tool is read-only, what side effects occur, rate limits, or data freshness. This is a significant gap for a generation tool.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and data sources.

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

Completeness2/5

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

Given no output schema and no annotations, the description is too brief. It doesn't mention return format (e.g., PDF, JSON), how to access the report, or what content is included. The agent lacks essential information to use the tool 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 covers 100% of parameters with descriptions. The description does not add additional meaning beyond the schema—no format hints or usage context for the parameters.

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

Purpose5/5

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

The description clearly states the action 'generate' and the resource 'due diligence report for a Swiss company', specifying the data sources (Zefix and UID Webservice). This distinguishes it from sibling tools which are mostly search/validation/get operations.

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 the tool is for generating a report, but it does not explicitly state when to use this vs. alternatives like get_company_by_uid or advanced_search. No exclusion criteria or alternative recommendations are given.

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

get_company_by_uidB

Get detailed company information from Zefix by UID. Optionally enriches data with UID Webservice information.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	Company UID in format CHE-XXX.XXX.XXX
`enrichWithUidData`	No	Enrich with additional data from UID Webservice (default: true)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only implies a read operation without stating side effects, authentication needs, or rate limits. It does not disclose behavioral traits beyond the basic action, leaving agents uninformed about potential exceptions or costs.

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 no wasted words. It efficiently conveys the core function and optional enrichment, achieving front-loaded clarity without redundancy.

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

Completeness3/5

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

For a simple get tool with no output schema, the description is adequate but incomplete. It does not specify what fields are returned, handle edge cases, or differentiate sufficiently from similar tools, leaving some gaps for an agent's 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?

Schema coverage is 100%, and the tool description does not add any meaning beyond what is already in the parameter descriptions. Baseline score of 3 applies as the schema suffices.

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

Purpose5/5

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

The description clearly states the action ('Get'), resource ('detailed company information'), and source ('from Zefix by UID'). It distinguishes from siblings by mentioning optional UID Webservice enrichment, providing a unique scope.

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

Usage Guidelines2/5

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

No explicit guidance is provided on when to use this tool versus alternatives like get_company_details_uid or validate_uid. The description implies use when a UID is available, but lacks exclusion criteria or context for choosing among sibling tools.

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

get_company_details_uidB

Get detailed company information using only the UID Webservice. This does not require Zefix authentication.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	Company UID in format CHE-XXX.XXX.XXX

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided; description mentions no authentication needed and use of UID webservice, which implies read-only behavior, but lacks details on side effects, rate limits, or return format.

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 concise sentences, front-loaded with purpose, no redundancy.

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

Completeness2/5

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

No output schema and description only says 'detailed company information' without specifying fields or structure. Lacks differentiation from sibling tool 'get_company_by_uid', leaving agent guessing.

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%; the parameter 'uid' is fully described in schema. Description adds no extra parameter meaning, so baseline 3 applies.

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 'Get detailed company information' using UID, differentiating from other tools by mentioning a specific webservice and no authentication requirement. However, sibling tool 'get_company_by_uid' exists with similar name, so distinction is not explicit.

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?

Indicates when to use (when you have a UID and want detailed info) and that no Zefix auth is needed, but does not provide when-not or compare to alternatives like 'get_company_by_uid'.

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

get_company_publicationsB

Get all SOGC publications for a specific company by UID using the Zefix API.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	Company UID in format CHE-XXX.XXX.XXX

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description must carry the burden of behavioral disclosure. It implies a read-only operation but provides no details on authentication requirements, rate limits, pagination, or the structure of the returned publications.

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

Conciseness4/5

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

The description is a single sentence that is front-loaded with the core action and resource. It is concise but could be slightly more informative without becoming verbose.

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

Completeness3/5

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

The tool is simple with one parameter, but the description does not explain what constitutes a 'publication', the expected return format, or any constraints like maximum results. Given the lack of output schema, this leaves the agent partially uninformed.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'uid' parameter with its format, so the description does not need to add much. The phrase 'by UID' adds minimal value beyond the schema, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('Get') and resource ('all SOGC publications') for a company identified by UID, clearly distinguishing it from sibling tools like 'get_company_by_uid' and 'get_company_details_uid' which retrieve different data.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'advanced_search' or 'search_companies'. The description does not mention prerequisites, limitations, or when to avoid using it.

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

get_daily_registrationsB

Get all company registrations and publications from SOGC (Swiss Official Gazette of Commerce) for a specific date using the Zefix API.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	Date in format YYYY-MM-DD

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It indicates a read operation but does not mention rate limits, authentication needs, pagination, response size, or any side effects. The lack of detail leaves the agent unaware of potential pitfalls like large result sets.

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

Conciseness5/5

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

The description is a single sentence of 17 words, conveying all essential information without waste. It is front-loaded and efficient.

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

Completeness2/5

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

Given no output schema, the description fails to describe the return format, fields, or pagination. For a tool that could return many registrations, missing information on limits or iterative retrieval makes it incomplete for the agent to use 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 coverage is 100% with one parameter 'date' described as 'Date in format YYYY-MM-DD'. The description adds minimal extra meaning beyond the schema, essentially restating the date's purpose. Baseline 3 due to high coverage, no additional semantic 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 specifies the verb 'Get', the resource 'all company registrations and publications', the source 'SOGC (Swiss Official Gazette of Commerce)', and the constraint 'for a specific date using the Zefix API'. It distinguishes from sibling tools like 'get_company_publications' which likely target a specific company, not daily data.

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 implicitly states usage for a specific date but provides no explicit guidance on when to use this tool versus alternatives like 'advanced_search' or 'get_company_publications'. No exclusions or prerequisites are mentioned.

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

search_companiesB

Search for Swiss companies using the Zefix API. Supports filtering by name, canton, legal form, and active status.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Company name to search for (minimum 3 characters, use * for wildcard)
`canton`	No	2-letter canton code (e.g., ZH, BE, GE)
`activeOnly`	No	Only return active companies (default: true)
`legalFormUid`	No	Legal form code (e.g., 0106 for AG, 0107 for GmbH)
`maxResults`	No	Maximum number of results to return (default: 30, max: 200)

TDQS

B3.3/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It mentions the API and filtering but omits details like response format, pagination behavior, rate limits, or authentication. Adequate but not comprehensive.

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?

Extremely concise single sentence (16 words) that front-loads the purpose. Every word earns its place without redundancy.

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

Completeness3/5

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

Given 5 parameters, no output schema, and no annotations, the description could cover response format, default behavior, or error handling. It mentions filters but lacks completeness for a search tool.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description lists filter types (name, canton, etc.) but adds no additional meaning beyond what the schema already provides for each parameter.

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: searching for Swiss companies with filters. It names the Zefix API and lists supported filters, but does not explicitly differentiate from sibling tools like advanced_search.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., advanced_search, get_company_by_uid). Missing context on prerequisites or exclusions, leaving the agent to infer usage.

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

validate_uidA

Validate a Swiss UID (Unternehmens-Identifikationsnummer) using the UID Webservice. Checks if the UID exists in the official register.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	UID to validate in format CHE-XXX.XXX.XXX

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions using a webservice and existence check but does not disclose error handling, rate limits, or response behavior. Minimal behavioral disclosure.

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 verb, no unnecessary words. Efficient and clearly structured.

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

Completeness4/5

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

For a simple one-parameter tool without output schema, the description covers the essential action. However, it omits details about what happens on invalid UID or service errors, leaving slight gaps for an agent.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description (format CHE-XXX.XXX.XXX). The description adds no new parameter-specific meaning beyond what schema already provides, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool validates a Swiss UID and checks existence in the official register. It is distinct from sibling tools like get_company_by_uid which retrieve details rather than validate.

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 for validation but provides no explicit guidance on when to use this tool versus alternatives like get_company_by_uid or search_companies. No when-not-to-use or context is given.

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

validate_vat_numberA

Validate a Swiss VAT (MWST) number using the UID Webservice. Checks if the VAT number is valid and currently active.

ParametersJSON Schema

Name	Required	Description	Default
`vatNumber`	Yes	VAT number to validate in format CHE-XXX.XXX.XXX

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. Description mentions using UID Webservice and checking 'currently active', but lacks details on rate limits, authentication, or side effects.

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, no redundancy, front-loaded with purpose and method.

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?

For a simple one-parameter validation tool with no output schema, the description provides sufficient information: what it does, the service used, and the check performed.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so description adds minimal value beyond schema. It restates the format but no new semantics.

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

Purpose5/5

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

The description clearly states the tool validates Swiss VAT numbers, checks validity and active status, and distinguishes from sibling 'validate_uid' by specifying VAT.

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?

No explicit guidance on when to use this vs alternatives like validate_uid. Usage is implied for Swiss VAT numbers, but lacks when-not-to-use or context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.0.0May 31, 2026
- First observedadvanced_search
- First observedgenerate_due_diligence_report
- First observedget_company_by_uid
- First observedget_company_details_uid
- First observedget_company_publications
- First observedget_daily_registrations
- First observedsearch_companies
- First observedvalidate_uid
- First observedvalidate_vat_number

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-05-31 20:45 across 9 tools

Disambiguation3/5

There is notable overlap between 'get_company_by_uid' and 'get_company_details_uid' (both retrieve company details via UID but from different sources), as well as between 'search_companies' and 'advanced_search' (both perform searches with slightly different filter sets). While descriptions clarify differences, an agent could easily select the wrong tool in many scenarios.

Naming Consistency3/5

Tool names predominantly follow a verb_noun pattern, but inconsistencies exist: 'advanced_search' uses an adjective prefix instead of a verb, while 'get_company_by_uid' and 'get_company_details_uid' include prepositions in the noun part. The mix of 'search_' and 'get_' verbs is acceptable, but the varying structures reduce predictability.

Tool Count5/5

With 9 tools, the set is well-scoped for a Swiss company registry server. Each tool addresses a distinct functional need (search, details, validation, publications, report generation) without unnecessary bloat or missing essential operations for this domain.

Completeness5/5

The tool surface covers all typical use cases for a read-only company registry: searching, retrieving detailed company info (via two complementary services), validating identifiers (UID and VAT), fetching publications and daily registrations, and generating due diligence reports. No obvious gaps are present.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ahel
io.ahel
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Government Data Cryptocurrency Open Data
2
Firmenwatch — Swiss Company Register A
ch.firmenwatch
Search and verify Swiss companies, UID status and register changes with dated official sources.
Government Data Open Data Search
61
openswissdata A
io.github.cammac-creator
Swiss customs (TARES), FINMA registry & NOGA/NACE/ISIC classifications. 9 MCP tools, free tier.
Government Data Open Data
92
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282

Related MCP Servers

register-mcp
Government Data Open Data
malkreide
A
license
A
quality
A
maintenance
Provides access to the Swiss Federal Commercial Register (Zefix) for company search, verification, and reference data, enabling natural language queries for public administration use cases.
Updated 4 days ago (2026-09-11 05:03 UTC)
9
MIT
bexio-mcp
CRM ERP Systems
valmiremini
A
license
A
quality
C
maintenance
A standalone MCP server for the bexio REST API, enabling interaction with bexio resources like contacts, invoices, and projects through natural language from any MCP client.
Updated 2 months ago (2026-07-01 04:03 UTC)
21
4 npm
MIT
ch-eli-mcp
Legal & Compliance Government Data
matematicsolutions
A
license
A
quality
A
maintenance
MCP server for Swiss federal legislation metadata via Fedlex, enabling search and retrieval of act details with ELI URIs, SR numbers, and multilingual support.
Updated 22 days ago (2026-08-24 13:55 UTC)
3
Apache 2.0
bexio-mcpofficial
ERP Systems CRM
nolen-ai
A
license
A
quality
A
maintenance
MCP server for the bexio API, enabling interaction with contacts, sales, accounting, projects, and more through 35 tools. Supports both PAT and OAuth authentication with read-only mode and tool group filtering.
Updated 2 months ago (2026-07-27 20:40 UTC)
35
4 npm
3
MIT

About Schwaizer

Zefix MCP Server

Features

Dual API Integration

Available Tools (9 tools)

Zefix API Tools

UID Webservice Tools

Combined API Tools

Installation

Configuration

Usage

Running the Server

Example Tool Calls

Search for companies (Zefix)

Get company details (Zefix + UID)

Validate UID (UID Webservice)

Generate due diligence report (Zefix + UID)

Get daily registrations (Zefix)

API Documentation

Zefix REST API

UID Webservice

Data Sources

Caching

Error Handling

Development

Project Structure

Running Tests

Linting

Scripts

License

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

bexio-mcpofficial