Swiss customs tariff (TARES), FINMA register, NOGA/NACE/ISIC codes. 3 free tools + search trial.
Scored across 7 tools
finma_search and kyc_check both search the FINMA register and warnings list by name, with only subtle differences (match_type labels and include_warnings vs top_k), so an agent could easily pick the wrong one. tariff_lookup and tariff_semantic_search also overlap since semantic_search accepts a tariff number as well as a description. The remaining tools (classify_text, company_check, cross_walk) are clearly distinct, but these two overlapping pairs pull the score down.
All names use snake_case and are descriptive, but they mix verb_noun (classify_text, finma_search, tariff_lookup, tariff_semantic_search) and noun_verb (company_check, kyc_check) patterns. cross_walk is idiomatic rather than following either convention. The set is readable and predictable in style, just not a single uniform pattern.
Seven tools is a well-scoped size for a Swiss open-data server spanning classifications, company registry, FINMA and tariffs. Each tool maps to a real function, though the finma_search/kyc_check pair suggests one tool could be redundant. Nothing feels padded or missing on count alone.
The surface covers the four apparent domains: activity classification (classify_text, cross_walk), company registry (company_check), financial supervision (finma_search, kyc_check) and customs tariffs (tariff_lookup, tariff_semantic_search). company_check explicitly omits FOSC publications, SECO sanctions and officers, which are acknowledged gaps but not necessarily core to the stated scope. Coverage is solid for the advertised lookups.
FREE TRIAL without a key: 20 calls per day per IP address in total for tariff_semantic_search, classify_text and finma_search. Each answer states the trial calls left; check every result on the NOGA publications of the Federal Statistical Office before use. Classify a business activity description (French, German, Italian or English) into the closest NOGA 2025 subclasses (6 digits) with their class (the NACE 2.1 class), official hierarchy and a similarity score, using a pinned multilingual mpnet model. A NOGA code as text lists its subclasses. Each answer states the index provenance and the classification reference version; combine with cross_walk for NACE, ISIC or NOGA 2008.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the returned labels; the search itself covers all four languages | fr |
| text | Yes | Business activity description in French, German, Italian or English, or a NOGA 2025 code (e.g. 62.10) | |
| top_k | No | ||
| scheme | No | NOGA_2025 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial non-annotation behavior: a 20-calls/day/IP quota shared across three tools, per-answer reporting of remaining trial calls, a pinned multilingual mpnet model, index provenance and reference-version disclosure, plus a correctness caveat to verify against official FSO publications.
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 blocks: trial/quota terms first, then the classification semantics and output. Every sentence carries information, though the free-trial framing echoes the title and pushes the core purpose slightly past the opening. Still efficient and reasonably 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?
With no output schema, the description carries the return-value burden and does so thoroughly: subclasses, NACE class, official hierarchy, similarity score, index provenance and reference version. It also signals the complementary cross_walk call, leaving nothing essential for an agent to infer.
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 only 50%: lang and text are documented, but top_k and scheme carry no schema descriptions. The description compensates partially by explaining the four supported languages and that a NOGA code passed as text lists its subclasses, but it never clarifies top_k behavior or the NOGA_2025 vs NACE_2.1 scheme choice, leaving a real gap.
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 specific verb ("Classify") and resource ("a business activity description") and names the exact output artifact: NOGA 2025 subclasses (6 digits) plus NACE 2.1 class, hierarchy and similarity score. It also distinguishes itself from the sibling cross_walk by routing cross-standard lookups there.
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?
Gives clear context: it names the free-trial quota shared with tariff_semantic_search and finma_search, notes the multilingual input scope, and directs the user to combine with cross_walk for NACE/ISIC/NOGA 2008. It stops short of an explicit when-to-use-this-instead-of tariff_semantic_search statement, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Swiss company by its UID (CHE-xxx.xxx.xxx): commercial register data (LINDAS), FINMA register entries and LEI records (GLEIF), each fact with its source and, when known, the date it was read, plus exact cross-checks between sources and checks of the registered address against the official localities and streets directories (swisstopo, when published). No score. When available, the commercial register status (active, in liquidation or deleted, with the deletion date) is read from Zefix (OFRC). FOSC publications, SECO sanctions and officers are not covered.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Swiss UID (CHE-xxx.xxx.xxx) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world and non-destructive traits, and the description still adds substantial behavior: per-fact source attribution with read dates, cross-checks between sources, swisstopo address validation only 'when published', and Zefix-derived register status with deletion dates. This is exactly the provenance/availability nuance annotations cannot express.
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?
Front-loaded with the verb and resource, then layered with data sources, coverage caveats and exclusions. Dense but every clause carries information; the parenthetical source names and 'when available' qualifiers are necessary rather than filler.
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?
No output schema exists, so the description must convey what comes back — and it does: sourced facts, read dates, cross-checks, address validation and register status, plus an explicit list of what is not covered. An agent knows the response shape and limits before calling.
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?
Only one parameter and schema coverage is 100%, so the schema already documents uid fully. The description repeats the CHE-xxx.xxx.xxx format rather than adding syntax or validation detail beyond the schema, so the baseline 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 specific verb and resource ('Look up a Swiss company by its UID') and enumerates the exact data domains returned (LINDAS commercial register, FINMA, GLEIF LEI, Zefix status), which differentiates it from siblings like finma_search or kyc_check without opening either schema.
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?
Gives clear scope boundaries and exclusions ('FOSC publications, SECO sanctions and officers are not covered'; 'No score'), which implicitly routes scoring-style needs to kyc_check. It stops short of explicitly naming the alternative tool or stating when this should be preferred over kyc_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find correspondences between NOGA 2008, NOGA 2025, NACE 2.0, NACE 2.1 and ISIC 4 activity codes (Swiss, EU and UN classifications). Returns the exact or approximate relation, its sources and the documented path. Never chains two non-exact relations; a non-exact correspondence needs expert validation.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code, with or without dot (01, 6201, 47.91). | |
| source | Yes | ||
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes beyond them by disclosing output semantics (exact vs approximate relation, sources, documented path) and a meaningful behavioral rule about not chaining non-exact relations and requiring expert validation for approximate matches.
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 tightly written sentences with the scope front-loaded and a critical caveat second. No filler, no restatement of the title, and every clause carries information an agent needs.
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 no output schema, the description does the work of describing the return contents (relation type, sources, documented path) and its reliability caveat. It is nearly complete for a 3-parameter lookup tool; only the directionality and self-mapping rules for source/target are left unspecified.
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 only 33%: the 'code' parameter is documented with format examples in the schema, and the two enum parameters are self-describing. The description adds value by enumerating the classification families and their geographic origin (Swiss/EU/UN), but says nothing about directionality of the mapping, whether source and target may coincide, or how ambiguity is resolved.
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 verb ('Find correspondences') and names the exact resources involved (NOGA 2008, NOGA 2025, NACE 2.0, NACE 2.1, ISIC 4), plus clarifying them as Swiss, EU and UN classifications. An agent immediately understands this is a cross-classification code mapping tool and can distinguish it from kyc_check and tariff_lookup.
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 an important operating constraint ('Never chains two non-exact relations; a non-exact correspondence needs expert validation'), which guides how to interpret and act on results. However, it never states when to reach for this tool versus the sibling tools, nor any prerequisites such as whether source and target may be identical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE TRIAL without a key: 20 calls per day per IP address in total for tariff_semantic_search, classify_text and finma_search. Each answer states the trial calls left; check every result on the official FINMA register before use. Search the FINMA register by entity name, tolerant of case, accents, legal forms (AG, SA, Sàrl, GmbH, Ltd), ae/oe/ue spellings and one or two typos per word. Results are ranked exact, word start, whole word, prefix, substring, all words in any order, then typo guesses, each labelled with match_type. Set include_warnings=true to also search the FINMA warnings list. Each answer states the FINMA data version.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Entity name, or a distinctive part of it (typos, accents and legal forms such as AG/SA/Ltd are tolerated) | |
| top_k | No | ||
| include_warnings | No | Also search the FINMA warnings list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial context beyond them: the per-IP daily call cap shared across three tools, the remaining-calls reporting, the FINMA data version disclosure, and the ranked match_type output. These are behavioral traits an agent cannot derive from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the trial constraint and verification warning before the search mechanics, which is the right priority. It is dense but each sentence carries distinct information (quota, verification, tolerance, ranking order, warnings toggle, data version); only the ranking enumeration risks feeling list-heavy.
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 no output schema, the description must convey return shape, and it partly does: ranked results labelled with match_type, remaining trial calls, and the FINMA data version. That is fairly complete for a search tool, though it does not describe result payload fields or pagination.
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 67% (name and include_warnings documented; top_k undocumented). The description reinforces name tolerance and include_warnings behavior, adding meaning about how matching works, though it does not clarify top_k beyond the schema's default and range.
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 specific verb+resource ('Search the FINMA register by entity name') and details the tolerance semantics (case, accents, legal forms, ae/oe/ue, typos). It distinguishes itself from siblings by naming classify_text and tariff_semantic_search in the shared trial quota, and it is clearly not kyc_check or cross_walk.
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?
Gives clear context: free trial without a key, 20 calls/day shared across three named tools, and a verification directive ('check every result on the official FINMA register before use'). It also flags include_warnings as an opt-in behavior. However it never states when to choose finma_search over kyc_check or cross_walk, so alternative selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the FINMA register of supervised institutions and the FINMA warnings list by name (case- and accent-insensitive). Returns the closest top_k authorised entities and warning entries (exact name, then whole word, then substring; all words in any order as a fallback) with the total number of matches. Only an identical name is reported as a FINMA warning-list match; a merely similar name is listed separately, to verify, and is never called a match. Use it for basic counterparty screening; no result is not a compliance certificate.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Entity name (or a distinctive part of it) | |
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only declare read-only/idempotent/safe). It discloses the ranking algorithm (exact name, whole word, substring, all-words fallback), that the total match count is returned, that only an identical name counts as a warning-list match while similar names are reported separately for verification, and the important caveat that a negative result is not a compliance certificate.
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?
Purpose is front-loaded in the first clause and each subsequent sentence carries distinct information (matching order, match semantics, caveat). Sentences are long with stacked parentheticals, which slightly hurts scannability, but there is no filler.
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 no output schema, the description carries the return burden and does so adequately: it names the returned items (closest authorised entities and warning entries) and the total match count. Only minor gaps remain (no note on rate limits or result-size behavior) for what is otherwise a complete two-parameter read 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?
Schema coverage is only 50% (top_k is undocumented in the schema), so the description must compensate. It explains top_k semantically ('returns the closest top_k ... entries') and adds case- and accent-insensitive matching for name, which the schema does not state. Bounds and defaults are left to the schema, which is acceptable.
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 specific verb (search) and two named resources (FINMA register of supervised institutions, FINMA warnings list) with the matching key (name). An agent can tell what it does, but the sibling tool 'finma_search' is not differentiated, leaving ambiguity about which FINMA search to pick.
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?
Gives a usage context ('Use it for basic counterparty screening') and a caution ('no result is not a compliance certificate'), which is useful framing. However it never states when to prefer this over the closely related 'finma_search' or any exclusions, so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the Swiss customs tariff (TARES). An 8-digit Swiss tariff number (dots allowed) returns the full line: designations in FR/DE/IT/EN, MFN duty, preferential regimes, restrictions and customs relief codes. A 2- to 7-digit HS prefix (for example the international HS6 code) lists the Swiss 8-digit lines under it. Every result carries an unofficial-copy notice that the agent must show to the end user.
| Name | Required | Description | Default |
|---|---|---|---|
| hs8 | Yes | Swiss tariff number: 8 digits for one line (dots allowed, e.g. 8471.3000), or a 2- to 7-digit HS prefix (e.g. the international HS6 code 847130) to list the Swiss 8-digit lines under it | |
| lang | No | fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world semantics, so the bar is lower. The description adds genuinely new behavioral context: every result carries an unofficial-copy notice the agent must show the end user, plus a breakdown of what the line contains (designations, MFN duty, preferential regimes, restrictions, relief codes).
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 tight sentences, front-loaded with the verb and resource, then the two input modes, then the notice obligation. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of describing the return payload (designations, duties, preferential regimes, restrictions, relief codes) and adds the mandatory unofficial-copy notice. The only real gap is the behavior of the lang parameter, which is left implicit.
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 50%: hs8 is fully documented in the schema and the description largely restates it (dots allowed, prefix behavior). The lang enum has no schema description, and the description only hints at it via 'designations in FR/DE/IT/EN' without stating that lang controls the output language. Baseline 3 is appropriate given partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (Swiss customs tariff / TARES), and clearly distinguishes itself from siblings cross_walk and kyc_check, which are unrelated domains. An agent can identify the operation and scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two usage modes — an 8-digit number returns one full line, a 2- to 7-digit HS prefix lists the Swiss lines under it — which tells the agent how to invoke it correctly. It does not name alternatives or exclusions, but the sibling tools are in different domains so that is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE TRIAL without a key: 20 calls per day per IP address in total for tariff_semantic_search, classify_text and finma_search. Each answer states the trial calls left; check every result on the official tariff at xtares.admin.ch before use. Find Swiss customs tariff (TARES) lines from a description of the goods in French, German, Italian or English, or from a tariff number. Each line is indexed with its official hierarchy (heading, intermediate texts, 8-digit line) in the four languages; ranking puts shared official words first and uses meaning (pinned multilingual mpnet model) as a tie-breaker and for synonyms. Returns the 8-digit code, its official path, a relative score, the TARES data version and the index provenance. Always inlines a non-official disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the returned designations; the search itself covers all four languages | fr |
| query | Yes | Description of a good in French, German, Italian or English, or a Swiss tariff number (2 to 8 digits, dots allowed) | |
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes well beyond that: it discloses the 20-calls-per-day trial quota shared across three tools, that each answer reports remaining calls, the ranking strategy (official shared words first, pinned multilingual mpnet embedding as tie-breaker/synonym handling), the returned fields, the TARES data version and index provenance. That is exactly the kind of context annotations cannot carry.
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 purpose sentence ('Find Swiss customs tariff lines from a description of the goods...') is buried after two preamble sentences about the free trial and disclaimer that largely duplicate the title. Every sentence is informative, but front-loading the quota notice over the actual function makes the opening less efficient for an agent scanning for purpose.
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 no output schema, the description carries the return-value burden and does so: 8-digit code, official path, relative score, data version, provenance, plus an always-inlined non-official disclaimer. Trial limits and verification expectations are also covered. Only minor gaps remain (error/empty-result behavior, meaning of the relative score scale).
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 67%: lang and query carry schema descriptions, top_k is bare (only default/min/max). The description reinforces the query semantics (goods description or 2-8 digit tariff number) and lang semantics (returned designation language vs. all-language search), but adds nothing for top_k or for ranking/truncation behavior of results. Baseline 3 is appropriate given the schema does most of the work.
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 names a specific verb and resource: it finds Swiss customs tariff (TARES) lines from a goods description or a tariff number, with multilingual indexing detail. It is clearly distinguishable from finma_search and classify_text in kind, though it never distinguishes itself from the sibling tariff_lookup, which is the tool most likely to be confused with it. Therefore clear but without full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the input type (a goods description or tariff number) and it adds a verification step ('check every result on the official tariff at xtares.admin.ch before use'). However, it never says when to prefer this over tariff_lookup for a plain number lookup, or over classify_text, so the agent must infer routing. Implied usage only.
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.
company_checkclassify_textfinma_searchtariff_semantic_searchclassify_textcross_walk1 field changedInput schema / properties / code / descriptionPrevious value: -"Code source, avec ou sans point (01, 6201, 47.91)."New value: +"Source code, with or without dot (01, 6201, 47.91)."entity_historyfinma_searchkyc_check2 fields changedInput schema / properties / name / descriptionPrevious value: -"Entity name (or substring)"New value: +"Entity name (or a distinctive part of it)"Input schema / properties / name / maxLengthAdded value: +200tariff_changelogtariff_lookup2 fields changedInput schema / properties / hs8 / descriptionPrevious value: -"8-digit Swiss tariff number"New value: +"Swiss tariff number: 8 digits for one line (dots allowed, e.g. 8471.3000), or a 2- to 7-digit HS prefix (e.g. the international HS6 code 847130) to list the Swiss 8-digit lines under it"Input schema / properties / hs8 / patternPrevious value: -"^\\d{8}$"New value: +"^[0-9][0-9. ]{1,11}$"tariff_semantic_searchstatent_lookupcross_walk1 field changedInput schema / properties / code / descriptionPrevious value: -"Source classification code (e.g. '01', '6201', '47.91')"New value: +"Code source, avec ou sans point (01, 6201, 47.91)."classify_textcross_walkentity_historyfinma_searchkyc_checkstatent_lookuptariff_changelogtariff_lookuptariff_semantic_searchSearch and verify Swiss companies, UID status and register changes with dated official sources.
Swiss commercial register: companies, officers, bankruptcy risk, and your monitored lists.
Verified Swiss company profiles for AI agents: search, read and contact firms via allowed actions.
11.3M entities, 10 countries, 12 tools. EU VAT (VIES), BORME, GLEIF, KYB. Free: 100 req/month.
Add one secure layer between your agents and this server.