Swiss commercial register: companies, officers, bankruptcy risk, and your monitored lists.
Scored across 6 tools
Each tool addresses a distinct query type: company details, company network, director mandates, registry events, new companies, and name search. No two tools overlap in primary purpose, so an agent can confidently select the right one.
All tools follow a consistent verb_noun pattern: get_company, get_company_network, get_director, list_events, list_new_companies, search_companies. The verbs get/list/search are all appropriate and uniform.
With 6 tools, the server is well-scoped for the Swiss commercial register domain. Each tool covers a core query pattern without redundancy or bloat, fitting comfortably in the ideal 3-15 range.
The set covers the primary lifecycle and lookup needs for company data: search, direct lookup, network exploration, person-centric queries, and event/new-company feeds. No critical gaps are apparent for read-only registry access.
Details of one Swiss company by its UID (CHE-...) or its Lundio slug. Seat, legal form, sector, statutory purpose, and the latest event in the commercial register.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Swiss UID (CHE-123.456.789 or CHE123456789), or a Lundio slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context beyond that by enumerating what the returned details include, particularly 'the latest event in the commercial register', which an agent cannot infer from the schema alone. It does not fully explain behavior when no company is found, but the annotations lower the bar.
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, information-dense sentence that front-loads what the tool returns and the accepted identifiers. No filler or redundant restatement of the title.
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 single-parameter lookup with strong read-only/idempotent annotations, the description covers the essential fields returned and the accepted inputs. It doesn't specify the exact response format, but no output schema exists and the scope is narrow enough that this is a minor gap.
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 uid parameter already explains both Swiss UID formats and the Lundio slug alternative. The tool description merely repeats this information without adding new meaning, 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?
Description names a clear verb/resource pair: fetch details for one Swiss company. It also specifies the identifier forms (UID or Lundio slug) and the exact fields returned (seat, legal form, sector, purpose, latest event), which distinguishes it from siblings like get_company_network and search_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for retrieving a single company by an exact identifier, which implies it should not be used for discovery or listing (search_companies, list_new_companies). It stops short of explicitly stating 'use search_companies when you do not have a UID or slug', so it loses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The group around one company: its officers, and for each of them the other Swiss companies they serve. This is how you find a group of companies that shares no name, only people. Withdrawn profiles are left out of the graph.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Swiss UID (CHE-...) or a Lundio slug. | |
| depth | No | 1 = officers only, 2 = their other companies too (default 2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description doesn't need to restate safety. It adds value by explaining that withdrawn profiles are excluded from the graph. It also clarifies the nature of relationships (officers and their other companies), which is behavioral context. However, it doesn't disclose depth mechanics or output limitations beyond the schema.
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. It front-loads the core concept (group around a company) and then adds detail about usage and exclusions. Each sentence provides distinct value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (graph traversal), the description is fairly complete. It explains what the graph includes and excludes, and the schema covers parameters. However, it doesn't explicitly state the output format (though no output schema exists), nor does it mention pagination or limits, which could be important for an agent. Since there's no output schema, some return format information might be needed, but the description's core intent is clear.
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%, so both parameters (uid and depth) are well documented. The description does not add parameter-specific details beyond the schema, but it does explain the graph concept. Baseline 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find a group of companies connected by shared people (officers). It uses a specific verb ('get') and resource ('company network'), and explains the graph concept. It distinguishes itself from siblings by clarifying it maps people to companies, which is not covered by get_company or get_director.
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 when to use this tool: when you need to find a network of companies that share people but not names. It explicitly states what is excluded ('Withdrawn profiles are left out'), providing some usage context. However, it does not explicitly mention alternatives or when not to use it, but the contrast with siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Swiss company a person serves or has served, by name. Returns their mandates with role and status, plus the people they sit with (co-officers). Identity is the name as published in the register, so exact homonyms merge: treat the result as a name, not as a verified individual. A person may have withdrawn their profile, in which case this returns an explicit refusal while the company records keep their name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Person's name as published, e.g. 'Dupont Jean-Marc', or a Lundio slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description's job is lighter. It adds valuable context by disclosing that exact homonyms merge (potential data caveat), that the result is a name not an individual, and that withdrawn profiles lead to an explicit refusal. These are behaviors not covered by annotations, adding to transparency.
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. It front-loads the core purpose (list mandates) early, then provides necessary caveats about identity and privacy. Every sentence adds value, with no wordiness. The structure flows logically from purpose to important nuances.
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 a single parameter, no output schema, and comprehensive annotations, the description is quite complete. It covers the key aspects an agent needs: what it returns (mandates with role, status, co-officers), the name semantics, and edge cases (homonyms, withdrawn profiles). There's a minor gap: it doesn't specify if the result is a list or a single object, but the semantic clarity compensates.
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 the 'name' parameter well, including examples and the alternative slug format. The description reinforces this by explaining the name is as published in the register and how identity works. Since schema coverage is 100% and the parameter is a simple string, the description adds context on the semantic meaning of the name, which is valuable.
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 all Swiss company mandates for a person by name, listing roles, status, and co-officers. It distinguishes itself from siblings by focusing on a person's mandates, not companies or events, and explicitly notes the identity is a name, not a verified individual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need a person's mandates and co-officers. It doesn't explicitly mention alternatives or when not to use it, but the scope is well-defined. For instance, it hints that for company-centric queries, one might use get_company instead, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registry publications (SHAB/FOSC) newest first: new registrations, changes, strike-offs, bankruptcies. The feed to answer 'what moved' in a canton or a period.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional event filter: HR01 new registration, HR02 change, HR03 strike-off, KK insolvency. | |
| limit | No | Maximum results (default 20, max 50). | |
| since | No | Only publications on or after this date (YYYY-MM-DD). | |
| canton | No | Optional canton filter, two-letter code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral details like 'newest first' and the notion of a 'feed', which imply pagination or a stream, and it clarifies the scope (canton/period). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the resource, order, and content; the second provides a concise use-case. It is front-loaded and efficient.
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?
While the tool has no output schema, the description does not specify the fields returned per publication or pagination behavior. It says 'feed' implying a list, but an agent would not know what details each entry contains. This is a gap given no output schema to compensate. The limit default is in the schema, so that is covered, but the return structure is not.
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% with descriptions for all four parameters. The description reinforces the meaning by grouping the kind values (new registrations, changes, strike-offs, bankruptcies) and tying the canton/since parameters to the 'what moved' use case, adding semantic value beyond the schema's individual field descriptions.
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 registry publications (SHAB/FOSC) with a specific ordering (newest first) and enumerates the event types covered (new registrations, changes, strike-offs, bankruptcies). This distinguishes it from sibling tools like list_new_companies (which likely only covers new registrations) and search_companies (which is a general search).
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 phrase 'The feed to answer what moved in a canton or a period' gives clear context on when to use it: for tracking changes over time or location. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_new_companies for only new registrations'), so it stops short of a full routing guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List companies recently entered in the Swiss commercial register for one canton. Useful for prospecting: newly registered companies in an area over a period.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (default 30, max 90). | |
| limit | No | Maximum results (default 20, max 50). | |
| canton | Yes | Canton, two-letter code (ZH, VD, GE, TI…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the temporal and geographic scoping context but does not disclose return format, pagination behavior, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, followed by a concise use case. Every word adds value, and the structure is easy to scan.
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 read-only list tool with well-documented parameters and strong annotations, the description covers the core purpose and use case. It does not describe the return format, but there is no output schema, so this is a minor gap given the tool's 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?
Schema description coverage is 100% for all three parameters (days, limit, canton). The description adds general context about 'recently entered' but does not clarify parameter semantics beyond what the schema already documents. Baseline 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 the verb 'List' and the resource 'companies recently entered in the Swiss commercial register for one canton'. It is specific about scope (recent, canton) and distinct from siblings like get_company or list_events, though it doesn't explicitly distinguish itself from search_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for prospecting' gives a clear use context, but it does not mention when to prefer this tool over alternatives (e.g., search_companies) or any exclusions. The guidance 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.
Search Swiss companies by registered name. Returns name, legal form, seat, canton, UID and the Lundio solvency score (12-month bankruptcy risk, SA and GmbH only). Source: Swiss commercial register — SHAB/FOSC/FUSC (SECO) and Zefix (EHRA).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 10, max 25). | |
| query | Yes | Start or fragment of the registered name (min. 2 characters). | |
| canton | No | Optional canton filter, two-letter code (e.g. ZH, VD, TI). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it specifies the return fields, the solvency score limitation to SA and GmbH only, and the underlying data sources.
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 concise sentences with no filler. It front-loads the core purpose, then packs the most relevant return fields and source context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with a fully documented schema and safety annotations, the description provides the essential output fields and data provenance. There is no output schema, so listing the return fields helps, though it does not describe pagination or explicitly tie to 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 100%, so the schema already documents the query, limit, and canton parameters. The description does not add significant parameter-level meaning beyond confirming that search is by registered name and that the score applies only to certain legal forms.
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 a specific action ('Search'), a clear resource ('Swiss companies'), and the matching criterion ('by registered name'). It also lists the return fields, which differentiates it from sibling tools like get_company and list_new_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for searching by a registered name fragment, which gives an agent useful context for when to select it. It does not explicitly mention when not to use it or name alternatives such as list_new_companies, but the search-by-name framing is sufficiently clear.
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.
get_companyget_company_networkget_directorlist_eventslist_new_companiessearch_companiesSearch 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.
Background check any company in the world: registration, executives, courts and finances.
UK company records from Companies House, with alerts on new filings, officer and status changes.
Add one secure layer between your agents and this server.
