Click on "Deploy 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., "@@aiwerk/mcp-server-swiss-company Is Swisscom AG still active in the commercial register?"
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.
MCP server for Swiss company data from official public sources: the commercial register (Zefix open data via LINDAS), the UID register of the Federal Statistical Office, and the Swiss Official Gazette of Commerce (SHAB).
It answers questions about one company at a time: who is this, is it active, is it VAT registered, what changed in the register and when, which companies does this fiduciary act for, and which companies were newly registered in a canton this week. It never downloads a source in bulk. Every tool call runs under a hard request budget.
npx -y @aiwerk/mcp-server-swiss-companyOr add it to your MCP client configuration:
{
"mcpServers": {
"swiss-company": {
"command": "npx",
"args": ["-y", "@aiwerk/mcp-server-swiss-company"]
}
}
}No API key is needed.
Related MCP server: mcp-server-zefix
Tool | What it answers | Requests |
| Companies whose registered name contains a text, or whose statutory purpose contains a word (per canton). Candidates with UID, legal form, address and purpose. | 1 |
| One company by UID: name and translations, legal form, commercial register and UID register status, legal address, purpose, VAT registration (status, since when, VAT number), identifiers. | 2 |
| The company's own register publications, newest first: registration, changes to officers, name, seat, address, purpose, capital, liquidation, bankruptcy, deletion. Full text plus the list of changed fields. | 2 + one per publication |
| Publications about other companies that name this one, e.g. as auditor, liquidator or merger partner, with a text snippet and a role hint. | 2 + one per publication |
| New registrations, changes or deletions in one canton over up to 31 days. With | 1, or 1 + one per row |
| Check digit of a UID or VAT number, and whether the UID register knows it and lists it as VAT registered. | 0 or 1 |
Start with ch_company_search. The name in the commercial register often differs from the one on a website, a letterhead or Google Maps (hyphens, "Dr." spacing, a different legal form), so search for a short, distinctive part of it and confirm the right candidate by address before using its UID.
Variable | Default | Description |
|
| Request budget per tool call, at most 200. A call that would need more fails and asks for a narrower question. |
|
| Timeout per request. |
| off | Set to |
Source | Used for | Terms relevant here |
LINDAS Zefix dataset | Search, purpose, municipality | Open government data: "Open use. Must provide the source." |
UID register public services | Status, legal address, VAT registration | Free. The public services allow 20 requests per minute per caller and block temporarily when exceeded. |
Amtsblattportal (SHAB) | Register history, mentions, publications per canton | Public portal, used through its publication search. |
Zefix web API (optional) | Register status, former names, auditors and audited companies, branches, takeovers, history before the portal's coverage | Not documented for third-party use, which is why it is off by default. The official Zefix REST API needs credentials from the Federal Office of Justice (zefix@bj.admin.ch). |
Every result carries a sources list with the attribution for the sources it used. Pass it on together with the data.
Request budget per call. Default 40. When a question would need more, the call fails with a message asking for a smaller limit, a shorter date window or a canton.
Spacing per source. At least 3.1 seconds between two UID register requests, 0.5 seconds for the others, per process.
Identifying User-Agent with the package name, version and repository.
Caching. Gazette publications do not change once published and are kept in memory for a day; register lookups for ten minutes.
Filter checks. The gazette API ignores some filter combinations without an error (for example subRubrics next to rubrics, or a misspelled parameter) and then returns unfiltered data. The server checks every list response against the requested canton, type and date window and fails instead of reporting unfiltered data.
Subject check. A search for a UID in the gazette also finds publications about other companies that merely name it. History and mentions are told apart by the UID in the publication's company block, not by the search hit.
The gazette portal returned no publications from before the second half of 2018 in testing. Older register history comes only from the optional Zefix web API.
The name search matches a substring of the registered name. It does not find "Muster Aufzuege" for "Muster Aufzüge", or a name without its hyphen.
A purpose search needs a canton; across all of Switzerland it takes ten seconds or more.
The gazette search serves the first 10,000 hits of a query; the per-canton listing is therefore limited to 31 days per call.
The UID register allows 20 requests per minute per caller. Several agents behind one IP address share that limit.
The current list of officers is not a register field: it is only visible through the publications that changed it.
No bulk export or crawling of any source.
No telephone directory data. The tel.search.ch terms forbid passing entries or the key on to third parties.
No domain registration data. The SWITCH acceptable use policy excludes advertising and market research.
No debt collection register (Betreibungsregister) data.
npm install
npm run build
npm test # unit tests, no network
npm run smoke # live test against the public sources, about 15 requestsTest fixtures are anonymized copies of real responses: the XML structure is kept, every company name, person, place and UID is replaced.
MIT
The company's own commercial register publications from the Swiss Official Gazette of Commerce (SHAB), newest first: registration, changes to officers, name, seat, address, purpose or capital, liquidation, bankruptcy and deletion, each with the full publication text and the list of changed fields. Publications in which the company only appears as auditor or liquidator of another company are left out; see ch_company_mentions for those.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The company UID in the form "CHE-123.456.789". Find it with ch_company_search. | |
| limit | No | Maximum publications to return, newest first. Default 10. | |
| since | No | Only publications on or after this date, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavior beyond that: newest-first ordering, inclusion of full publication text and changed-fields lists, and the auditor/liquidator exclusion rule. 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 dense sentences: the first front-loads the resource, ordering, and content; the second handles the exclusion and sibling pointer. Every clause carries meaning, with no filler or repetition.
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 read-only list tool with 3 parameters and no output schema, the description is complete: it covers scope, ordering, what is included in output (full text and changed fields), what is excluded, and which sibling to use instead. An agent has enough to invoke 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?
Schema coverage is 100%; uid, limit, and since all have their own descriptions. The description does not add parameter-level detail such as date format or default limit, but the schema already documents these, so the baseline of 3 applies.
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?
States a precise scope: the company's own SHAB publications, newest first, with a concrete list of event types (registration, officer changes, name/seat/address/capital changes, liquidation, bankruptcy, deletion). It explicitly differentiates itself from ch_company_mentions by noting what is left out, 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?
Tells the agent when to use this tool ('the company's own commercial register publications') and explicitly names the alternative for the excluded case: 'see ch_company_mentions for those.' It even specifies the exclusion condition (company appears only as auditor or liquidator of another company), which is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gazette publications about OTHER companies that name this one, for example as auditor, liquidator or merger partner, with a text snippet and a role hint. Shows which companies a fiduciary or audit firm works for.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The company UID in the form "CHE-123.456.789". Find it with ch_company_search. | |
| limit | No | Maximum mentions to return, newest first. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already show readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context by disclosing that results include a text snippet and a role hint, and that the focus is on mentions in gazette publications about other companies. This goes 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 two sentences with no filler. It front-loads the core scope ('Gazette publications about OTHER companies that name this one') and then gives a practical use case. Every phrase 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 read-only tool with only 2 parameters and no output schema, the description covers the purpose, result content (snippet and role hint), and a use case. It does not mention pagination or ordering, but the limit parameter description in the schema already covers newest-first ordering. Sibling differentiation is clear from the 'OTHER companies' phrasing.
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%, so the uid and limit parameters are already well-documented. The description does not add additional parameter-specific guidance, but the baseline of 3 is appropriate because the schema carries the full meaning of both 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 verb and resource: it lists gazette publications about OTHER companies that name this one, with text snippet and role hint. It also differentiates from siblings by emphasizing 'OTHER companies' and provides a concrete use case (showing which companies a fiduciary or audit firm works for), making it distinct from ch_company_profile or ch_company_history.
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 and a specific use case ('Shows which companies a fiduciary or audit firm works for'), implying when this tool is useful. It does not explicitly name alternatives or state when not to use it, but the 'OTHER companies' scope is enough to differentiate it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the official registers hold about one company, by UID: name and translations, legal form, commercial register and UID register status, legal address, statutory purpose, VAT registration (status, since when, VAT number) and identifiers. With the Zefix web API enabled it adds seat, former names, auditors, the companies it audits, branches and takeovers.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The company UID in the form "CHE-123.456.789". Find it with ch_company_search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by detailing exactly what data fields are included and by disclosing that responses are enriched with additional fields when the Zefix web API is enabled. It provides meaningful value 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?
Two sentences carry all the essential information with no filler. The main scope is front-loaded, the field list is compact but complete, and the conditional Zefix enrichment is stated in a single additional sentence. Every clause 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 one-parameter read-only tool with no output schema, this description is complete enough for an agent to select and invoke it correctly. It specifies the required input, the source of data, the exact fields the caller can expect, and the optional environment-dependent enrichment. Nothing essential is missing.
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%: the single uid parameter is already documented with format, length, and a pointer to ch_company_search. The description's 'by UID' wording adds no real semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: the official register profile of one company identified by UID, then enumerates the concrete data fields. The resource and scope are specific, and with the 'by UID' qualifier it is immediately distinguishable from sibling tools like ch_company_search, history, or mentions.
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 right use case: use it when you already have a company UID and want the official register snapshot. However, it does not explicitly state when to prefer alternatives, and the only pointer to ch_company_search lives in the parameter schema, not in the description itself, so exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Swiss companies in the commercial register by part of their registered name, or by a word in their statutory purpose (match="purpose", needs a canton). Returns candidates with UID, legal form, address and purpose. The name match is a substring of the registered name, so a name from a website or Google Maps may need a shorter, distinctive part. When several candidates come back, confirm the right one by address before using its UID.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum candidates, default 20. | |
| match | No | "name" (default) searches registered names, "purpose" searches the statutory purpose. | |
| query | Yes | Text to look for. With match="name" (default), part of the registered company name, e.g. "Muster Treuhand". With match="purpose", a word from the statutory purpose, e.g. "Buchführung". | |
| canton | No | Two-letter canton code such as BE or ZH. Required for match="purpose". | |
| legal_form | No | AG, GmbH, Einzelunternehmen, Genossenschaft, Verein, Stiftung, or an eCH-0097 code such as 0106. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and open-world; the description adds useful behavioral detail beyond that, such as the substring behavior, the canton requirement for purpose searches, and the advice to confirm candidates by address. It does not disclose every edge case or rate limit, but the added context is meaningful for correct use.
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, front-loaded with the core purpose, and every sentence earns its place: search behavior, returned fields, substring caveat, and disambiguation advice. No redundant filler or restatement of obvious schema details.
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?
Despite having no output schema, the description explains what results contain and how to handle ambiguous results. The schema fully documents the five parameters, and annotations cover the safety profile. Nothing essential for an agent to decide when to call this tool is missing.
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%, so baseline is 3. The description adds a small amount of real-world guidance, such as using a shorter, distinctive name fragment and confirming by address, but it largely restates parameter information already present in the schema, especially for query, match, and canton.
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 opens with a specific verb and resource ('Find Swiss companies in the commercial register') and clearly distinguishes the two search modes: by registered name or by statutory purpose. It names the returned entity fields, which lets an agent separate this search tool from sibling tools like ch_company_profile or ch_validate_uid.
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 use context: name matching is substring-based, purpose matching requires a canton, and results should be disambiguated by address before using a UID. It does not explicitly contrast this tool with sibling alternatives, but the intended workflow is evident from the concrete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New commercial register entries in one canton over a date window of up to 31 days, newest first, from the Swiss Official Gazette of Commerce. type="mutation" or "deletion" lists changes or deletions instead. details=true adds name, UID, address, capital and purpose per row at one request each (at most 25 rows). Page through larger windows with page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 0. | |
| type | No | registration (new companies, default), mutation (changes) or deletion. | |
| limit | No | Rows per page, default 20. | |
| since | No | First publication date, YYYY-MM-DD. Default: 7 days before until. | |
| until | No | Last publication date, YYYY-MM-DD. Default: today. | |
| canton | Yes | Two-letter canton code, e.g. BE. Required. | |
| details | No | false (default): date, type and title only, one request per page. true: also name, UID, address, capital and purpose, one extra request per row, at most 25 rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important behaviors: results are newest first, the date window is capped at 31 days, details=true costs one extra request per row with a 25-row cap, and larger windows require pagination. This gives an agent a realistic model of cost and behavior.
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?
Three dense sentences cover the core purpose, parameter variations, and pagination behavior without wasted words. The key function is front-loaded and every sentence adds operational 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 read-only nature, 100% schema coverage, and absent output schema, the description is complete enough for correct invocation. It tells the agent what the basic rows return, what details adds, how to paginate, and what limits apply.
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 already describes all 7 parameters, so the baseline is 3. The description adds meaning beyond the schema by stating the 31-day window limit, newest-first ordering, the 25-row ceiling for details, and the per-row request cost for details=true.
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 identifies the tool's action and resource: retrieving new commercial register entries for one canton over a date window from the Swiss Official Gazette of Commerce. It also distinguishes this publication-feed tool from the sibling company-level tools by framing it around gazette entries, dates, and cantons.
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 gives clear context for when to use the tool: for new commercial register entries in a canton over a date window. It also explains how to use type for mutations/deletions, details for richer rows, and page for pagination, but it does not explicitly exclude alternatives or compare against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a Swiss UID or VAT number: the check digit locally, then (unless lookup=false) whether the UID register knows it, its status, and whether the company is currently VAT registered.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | A UID or VAT number in any common form, e.g. "CHE-123.456.789" or "CHE123456789 MWST". | |
| lookup | No | true (default): also look the UID up in the UID register. false: check digit only, no request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world, and the description adds meaningful behavioral detail: it performs a local check-digit verification first, then optionally performs a network lookup to the UID register, returning status and VAT-registration information. This clearly discloses the two-step behavior and the network call 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?
A single, well-constructed sentence front-loads the verb and object, then efficiently describes the check flow, the default behavior, and the optional lookup=false switch. There is no filler, repetition of schema details, or unnecessary background.
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 tool with two parameters, read-only annotations, and no output schema, the description covers the input type, the default network lookup, and the key result dimensions (register recognition, status, VAT registration). It does not specify the exact response fields or error behavior, but those are not strictly necessary for an agent to decide whether to invoke this tool.
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 already fully documents both parameters, including format examples and the lookup default. The description adds some value by associating lookup with the local-check vs register-lookup sequence, but it does not introduce substantive parameter semantics beyond what the schema already provides.
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 uses a specific verb ('Check') and a clear resource ('a Swiss UID or VAT number'), then breaks down exactly what checking involves: local checksum validation and optional UID-register lookup. It is immediately distinguishable from sibling tools like ch_company_search or ch_company_profile, which focus on company data rather than identifier validation.
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 intended use case is implied by the description: validate a UID or VAT number and optionally verify its registration status. However, it never explicitly contrasts this with sibling tools or states when not to use it, and the only conditional guidance ('unless lookup=false') is about an option rather than tool selection.
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.
v0.1.0ch_company_historych_company_mentionsch_company_profilech_company_searchch_register_publicationsch_validate_uidScored across 6 tools
Each tool targets a distinct operation: search, history, mentions, profile, register feed, and UID validation. Overlap between search and profile is clarified by UID-based lookup vs name-based candidate search, and history vs mentions explicitly separates own vs third-party publications.
All tools share the ch_ prefix and snake_case, but verb placement varies: ch_company_search and ch_validate_uid are verb-focused while ch_company_history, ch_company_mentions, ch_company_profile, and ch_register_publications are noun-focused. This is mostly predictable and readable, with only minor stylistic inconsistency.
Six tools cover search, detail, validation, and publication querying without redundancy. This is well within the ideal range and each tool earns its place for a focused Swiss company register server.
The set provides a complete lifecycle for company data: find candidates, validate identifiers, view the official profile, and inspect both own and third-party publications. There are no obvious dead ends, and references to related tools fill any potential gaps.
Search and verify Swiss companies, UID status and register changes with dated official sources.
Official company and director data: search, profiles, filings, and name normalization.
Swiss customs (TARES), FINMA registry & NOGA/NACE/ISIC classifications. 9 MCP tools, free tier.
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
