Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-zefix Search for Novartis on Zefix"
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.
Look up any Swiss company directly from Claude.
An MCP server that connects Claude to Zefix, Switzerland's official company register (Handelsregister). Zefix is operated by the Federal Office of Justice and provides authoritative data from all 26 cantonal commercial registers -- company details, legal forms, audit firms, corporate history, and official gazette publications.
"Search for Novartis on Zefix"
"Find all foundations in Basel"
"Who audits Novartis AG?"
"What companies has Novartis taken over?"
"Show me all branches of KIBAG Bauleistungen AG"
"Get the corporate structure for CHE-467.005.033"
"Show me the corporate history of Huber Baustoffe AG"
"What capital changes has cohaga AG had recently?"
"Find all GmbHs in Zurich"
"List all Swiss legal forms in German"
Related MCP server: SwissRegister
Connect directly -- no API key, no credentials, just the URL.
Claude.ai:
Settings > Customize > Connectors > Add custom connector:
URL: https://mcp-server-zefix.contextfor.ai/mcp
Claude Code:
claude mcp add --transport http zefix https://mcp-server-zefix.contextfor.ai/mcpclaude mcp add zefix -- uvx mcp-server-zefixOr add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"zefix": {
"command": "uvx",
"args": ["mcp-server-zefix"]
}
}
}Tool | Description |
| Search by name (wildcards supported), filter by canton and legal form |
| Full company profile: address, purpose, audit firm, takeover history, branch offices, previous names |
| Same as above, using the CH-ID identifier |
| Head office and all branch offices in a table with full addresses. Works from any branch UID. |
| SHAB timeline: board changes, capital changes, mergers, address changes, and more |
| All Swiss legal forms (AG, GmbH, Stiftung, etc.) with IDs for filtering |
All tools accept a language parameter (de, fr, it, en). Output labels use official Zefix terminology in the selected language.
A company lookup returns:
Identifiers -- name, UID, CH-ID, status, legal form
Location -- registered office, full address
Purpose -- the company's stated business purpose
Audit firm -- name and UID of the auditor
Corporate history -- companies absorbed, acquisitions, previous names
Corporate structure -- head office and all branch offices with addresses, displayed as a table
Branch offices -- all registered branch locations
SHAB publications -- timeline of legally significant events from the Swiss Official Gazette (board changes, capital changes, mergers, purpose changes)
Cantonal register link -- direct link to the full excerpt with board members and signatories
Works with zero configuration using the public Zefix API. For the official authenticated API, set these environment variables:
Variable | Default | Description |
|
| API base URL |
| (none) | Username for ZefixPublicREST API |
| (none) | Password for ZefixPublicREST API |
To use the official API, request credentials from zefix@bj.admin.ch, then:
{
"mcpServers": {
"zefix": {
"command": "uvx",
"args": ["mcp-server-zefix"],
"env": {
"ZEFIX_BASE_URL": "https://www.zefix.admin.ch/ZefixPublicREST/api/v1",
"ZEFIX_USERNAME": "your-username",
"ZEFIX_PASSWORD": "your-password"
}
}
}
}git clone https://github.com/johnphilipp/mcp-server-zefix.git
cd mcp-server-zefix
uv sync --all-extras
uv run ruff check . # lint
uv run pytest tests/ -v # test (68 tests, all use fakes, no network)
npx @modelcontextprotocol/inspector uv --directory . run mcp-server-zefix # interactiveFollows Architecture Patterns with Python (Percival & Gregory):
Domain models (models.py) -- frozen dataclasses (Company, LegalForm, ShabPublication), domain exceptions, no infrastructure imports
Port + adapter (zefix_client.py) -- AbstractZefixClient protocol; HttpZefixClient translates HTTP to domain objects and httpx exceptions to domain exceptions
Service layer (server.py) -- handle_* functions accept the abstract client, never import httpx
Localization (i18n.py) -- centralized label translations (de/fr/it/en) using official Zefix terminology
Fakes over mocks -- tests use FakeZefixClient, a working in-memory implementation; test files never import httpx
The server supports remote deployment via Streamable HTTP transport. See Dockerfile, docker-compose.prod.yml, and Caddyfile for a Docker + Caddy setup with auto-HTTPS.
MIT
Get detailed information about a Swiss company by its CH-ID.
The CH-ID is an alternative identifier used in the Swiss commercial
register system.
Args:
chid: The CH-ID identifier (e.g. CH27030000714).
language: Response language (de, fr, it, en).
| Name | Required | Description | Default |
|---|---|---|---|
| chid | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful context about the CH-ID concept and language options, but does not disclose additional behavioral traits such as error handling, response format, or edge cases, so transparency is adequate but not enhanced beyond 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 concise and well-structured, starting with the main purpose, then a brief explanatory note about CH-ID, and an Args list. It avoids fluff and is easy to scan, though the Args section partially duplicates schema information.
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?
With an output schema present and clear annotations, the description provides enough context for correct invocation. It explains the unique identifier and language parameter. The only missing piece is explicit guidance on when to use this tool vs. sibling tools, but that is a minor gap given the overall simplicity.
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 schema provides only field names and types, but the description's Args section explains both parameters with real-world examples (e.g., CH27030000714) and lists acceptable language values (de, fr, it, en). This significantly compensates for the 0% schema description 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 states 'Get detailed information about a Swiss company by its CH-ID', which is a specific verb+resource+identifier pattern. It clearly distinguishes from sibling tools like get_company_by_uid by explicitly naming the CH-ID as the lookup key.
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 when a CH-ID is available, and explains that CH-ID is an alternative identifier. However, it does not explicitly mention when to prefer this tool over alternatives (e.g., get_company_by_uid) or any exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a Swiss company by its UID number.
The UID (Unternehmens-Identifikationsnummer) is the unique identifier
for Swiss companies. Accepts various formats like CHE-123.456.789,
CHE123456789, or just 123456789.
Args:
uid: Company UID in any format (e.g. CHE-123.456.789 or CHE123456789).
language: Response language (de, fr, it, en).
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful input format flexibility (accepts various UID formats) and language options, but does not disclose additional behavioral traits like data freshness, rate limits, or output structure. Annotations already indicate read-only safety, so the bar is lower; this scores as adequate but not outstanding.
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 well-structured with a clear purpose, an explanatory note about UID, and an Args section. It is slightly longer than necessary but every sentence serves a purpose, especially given the lack of schema descriptions.
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?
For a simple lookup tool with an output schema present, the description sufficiently covers purpose, parameters, input formats, and language. It does not explain return values, but the output schema presumably does. It is complete for the tool's complexity, though could mention when to prefer sibling tools.
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 0%, so the description must compensate. It fully explains both parameters: uid (with examples of accepted formats) and language (with allowed values de, fr, it, en). This goes well beyond the schema's simple type definitions.
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 resource 'detailed information about a Swiss company by its UID number,' which distinguishes it from siblings like get_company_by_chid and search_companies. The specificity of UID-based lookup makes the purpose unmistakable.
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 use when you have a UID, but it does not explicitly mention alternatives or when not to use this tool. It lacks a clear 'use search_companies if you don't have a UID' or similar guidance, so the usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SHAB publications (Swiss Official Gazette) for a company.
Returns a timeline of legally significant events: board changes,
capital changes, mergers, address changes, purpose changes, etc.
Args:
uid: Company UID in any format (e.g. CHE-123.456.789 or CHE123456789).
language: Response language (de, fr, it, en).
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context about the timeline of events (board changes, capital changes, mergers, etc.), but does not disclose rate limits, auth, or pagination. No 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?
Description is concise and front-loaded with the main purpose. The args section clearly lists parameters with useful details, every sentence earns its place.
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?
For a 2-parameter read-only tool with an output schema, the description is complete. It explains what events are included and provides parameter syntax, making it sufficient for correct invocation.
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 has no property descriptions (0% coverage). The description fully compensates by explaining both parameters: uid format with examples, and language options with valid values.
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 'Get SHAB publications (Swiss Official Gazette) for a company' with a specific verb and resource. It distinguishes from sibling tools like search_companies and get_company_by_uid by focusing on publications timeline.
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 for retrieving legally significant events for a company, but does not explicitly state when to use this over alternatives or provide exclusions. Context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the corporate structure (head office and branches) of a Swiss company.
Shows the parent company (Hauptniederlassung) and all its branch offices
(Zweigniederlassungen) in a table with full addresses. Works whether you
pass the UID of the head office or any branch — the full structure is
returned either way.
Fetches detail for up to 50 branches. May take a while for large
structures since each branch requires a separate API call.
Args:
uid: Company UID in any format (e.g. CHE-105.807.648 or CHE123456789).
language: Response language (de, fr, it, en).
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals key behavioral traits: the output is a table with full addresses, the tool works with either UID type, it fetches up to 50 branches, and performance may be slow due to per-branch API calls. This adds substantial operational context that annotations alone do not convey.
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 well-structured and front-loaded, with the purpose stated in the first sentence. Subsequent sentences add necessary operational details without redundancy, making every sentence meaningful.
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?
The description is complete for a tool with moderate complexity: it covers input semantics, output format (table with addresses), branch limit, and performance characteristics. The presence of an output schema means return-value details are not needed, and the description provides sufficient context for correct invocation.
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 zero schema description coverage, the description fully compensates by explaining the uid format with concrete examples and listing the allowed language values (de, fr, it, en). This gives practical guidance beyond the bare schema properties.
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 retrieves the corporate structure (head office and branches) of a Swiss company, with specific behavior for head office or branch UIDs. This distinguishes it from sibling tools like get_company_by_uid by focusing on the full organizational hierarchy.
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 the use case: when you need the full structure with addresses, not just a single company record. It states that both head office and branch UIDs are accepted, clarifying when it can be used. However, it does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Swiss legal forms (Rechtsformen) recognized by Zefix.
Useful for understanding legal form IDs returned in search results,
or for filtering searches by legal form.
Args:
language: Language for legal form names (de, fr, it, en).
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's additional context about listing legal forms and language support adds marginal value. It does not contradict annotations and provides enough behavior context for an agent, but does not go beyond what annotations already imply.
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 concise, with a clear main statement, a brief usage note, and an argument spec. Every sentence adds value, and it is well-structured with the purpose 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?
For a simple list tool with one optional parameter, an output schema, and annotations, the description covers purpose, usage, and parameter semantics completely. It leaves no significant gaps and is fully sufficient for an agent to use it correctly.
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 single parameter 'language' is described with allowed values (de, fr, it, en), adding meaning beyond the schema which only specifies type and default. This fully compensates for the 0% schema description 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 lists all Swiss legal forms recognized by Zefix, using the specific verb 'list' and naming the resource. This distinguishes it from sibling tools that focus on company searches and details.
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?
It provides clear context by explaining the tool is useful for understanding legal form IDs in search results or filtering searches by legal form. It does not explicitly mention alternatives or when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Swiss companies in the Zefix register by name.
Use * as wildcard (e.g. "Novartis*" or "*pharma*"). Returns a list of
matching companies with UID, legal form, and registered office.
Args:
name: Company name to search for. Supports * wildcard.
canton: Two-letter canton code (e.g. ZH, BE, GE). Empty for all.
active_only: If true, only return currently active companies.
language: Response language (de, fr, it, en).
max_results: Maximum number of results to return (1-500).
offset: Pagination offset for retrieving additional results.
legal_form_ids: Comma-separated legal form IDs (e.g. "3,4").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| canton | No | ||
| offset | No | ||
| language | No | en | |
| active_only | No | ||
| max_results | No | ||
| legal_form_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, establishing the safe read-only nature. The description adds valuable behavioral context: wildcard support, the list of returned fields (UID, legal form, registered office), pagination via offset, and language selection. This extends beyond the annotations without contradicting them.
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 compact (~100 words), opens with the core purpose in the first sentence, and then uses a neatly formatted args list. Every sentence adds operational value, with no filler or redundant statements.
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?
All 7 parameters are described, the search behavior (wildcards, filters) is clear, and the return format is summarized (list with UID, legal form, office). An output schema exists, so deep return-value documentation is unnecessary. The tool's moderate complexity is fully covered by the description.
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 0% schema description coverage, the description fully compensates by explaining every parameter: name with wildcard, canton as two-letter code, active_only filter, language choices, max_results range, offset for pagination, and legal_form_ids as comma-separated values. This turns an otherwise opaque schema into a usable interface.
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 primary function: 'Search Swiss companies in the Zefix register by name.' This is a specific verb (Search) with a well-defined resource (Swiss companies in Zefix register) and method (by name), effectively distinguishing it from sibling tools that focus on exact identifier lookups (get_company_by_uid, get_company_by_chid) or static lists (list_legal_forms).
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 explains how to use the tool (e.g., wildcard syntax, parameter options) but does not explicitly state when to prefer this tool over alternatives. There is no mention of 'use get_company_by_uid for exact matches' or similar exclusions. The use case is implied by the name-based search focus, but not directly articulated as a decision guide.
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. Dates show when Glama detected each change.
v0.4.0get_company_by_chidget_company_by_uidget_company_publicationsget_company_structurelist_legal_formssearch_companiesThe tools are mostly distinct, but get_company_by_uid and get_company_by_chid both retrieve detailed company info and could be confused. However, the descriptions clearly differentiate them by identifier type, and search/list tools are unambiguous.
All tool names follow a consistent verb_noun pattern (search, get, list) with snake_case throughout. The two get_company_by_* variants are uniformly structured.
Six tools is an appropriate scope for a Swiss company register server, covering search, lookup, and ancillary data without redundancy or bloat.
The tool set covers the core functionality of the Zefix register: search, details by identifier, legal forms, publications, and corporate structure. Minor gaps exist (e.g., no direct address lookup or historical searches), but nothing critical for the apparent domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and verify Swiss companies, UID status and register changes with dated official sources.
Swiss customs (TARES), FINMA registry & NOGA/NACE/ISIC classifications. 9 MCP tools, free tier.
Live data from 27 official national company registries. Unmodified. For KYB and due diligence.
German Handelsregister + Austrian Firmenbuch for AI agents: master data, financials & ratios.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/johnphilipp/mcp-server-zefix'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
