Skip to main content
Glama

Find Swiss companies by name, purpose, canton, legal form, industry, location and AI lead score

search_companies
Read-onlyIdempotent

Search Swiss companies of every legal form: name, canton, legal form, industry, location, registration date, capital, discovered contact details, and the AI block (lead/viability score, mailbox-company and dissolution flags, size, confidence tier, buyer profiles, growth signals). Nothing is silently ignored — an unknown closed-set value or a free-text term under 3 characters is rejected — so an empty page is a real zero for this dataset, which holds only companies named in recent SHAB publications; it is not evidence the company doesn't exist in the register at all — try find_company_by_name against the live register instead. Every AI filter matches only analysed companies, so an empty page there means none analysed matched; analysisStatuses says how much was in scope. purpose is the exception and the way to ask what a company does: it searches the register's own purpose clause, which every company has, and the English AI summary together, so an unanalysed company is still found by its own words, and with no sort the most relevant come first. Unscored companies sort last, so pair a score sort with its minimum. Rows carry the filterable fields only — get_companies for the purpose, address, contact data and full AI block.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity / town name (partial match, min 3 chars)
sizeNoPage size, max 100 (default 20)
sortNoOrdering: REGISTRATION_DATE_DESC (default, or relevance when a purpose term is given), REGISTRATION_DATE_ASC, LEAD_SCORE_DESC, VIABILITY_SCORE_DESC. Companies with no score sort last, so a score ordering is not a substitute for the matching minimum filter.
cursorNonextCursor from the previous page; omit to start at the beginning. Opaque — pass it back verbatim, and keep the same filters and sort or it is rejected.
searchNoFree-text match on UID, CH-ID, or the firm name of legal entities (min 3 chars; shorter is rejected). Sole-proprietor/partnership names are not name-searchable.
streetNoStreet name (partial match, min 3 chars)
cantonsNoTwo-letter canton codes, e.g. ["ZH","BE"]; anything else is rejected
purposeNoWhat the company does (min 3 chars per term). Terms are alternatives; words inside one term must all appear. Nothing is translated: the purpose clause is written in German, French or Italian, and one language finds only the companies that filed in it, so pass all three wordings — ["Photovoltaik","photovoltaique","fotovoltaico"]. An English term reaches the AI summary instead, so on its own it finds analysed companies only. Words match as prefixes and accents are ignored.
zipCodeNoPostal code (prefix match), e.g. "80" or "8001"
hasEmailNotrue keeps only companies with a discovered email
industryNoAI industry or sub-industry (partial match, min 3 chars), e.g. "software"
statusesNoStatuses: ACTIVE, CANCELLED, BEING_CANCELLED
capitalMaxNoMaximum nominal capital, in the company's own currency
capitalMinNoMinimum nominal capital, in the company's own currency
hasContactNotrue keeps only companies with a discovered email or website
hasWebsiteNotrue keeps only companies with a discovered website
legalFormsNoLegal forms, by abbreviation or full name in any official language, e.g. ["AG","GmbH"], ["SA","Sàrl"] or ["Genossenschaft"]; an unknown one is rejected. Catalog: vetari://allowed-values/legalForm
isDissolvedNotrue keeps only companies the AI marks dissolved, false only those it marks not dissolved; no verdict matches neither
likelyNeedsNoAI likely needs the company may have, e.g. ["BOOKKEEPING","CORPORATE_LAW"]; one of BOOKKEEPING, STATUTORY_AUDIT, TAX_ADVISORY, PAYROLL_SERVICES, CORPORATE_LAW, EMPLOYMENT_LAW, IP_TRADEMARK, CONTRACT_LAW, REGULATORY_COMPLIANCE, RECRUITING, HR_OUTSOURCING, BUSINESS_BANKING, CORPORATE_FINANCE, BUSINESS_INSURANCE, PENSION_BENEFITS, IT_INFRASTRUCTURE, SOFTWARE_DEVELOPMENT, CYBERSECURITY, DIGITAL_MARKETING, WEB_ECOMMERCE, OFFICE_SPACE, FACILITY_MANAGEMENT, LOGISTICS_WAREHOUSING, PROCUREMENT, INDUSTRY_SPECIFIC
companySizesNoAI size buckets: SOLO, MICRO, SMALL, MEDIUM, LARGE, UNKNOWN
maxLeadScoreNoMaximum AI lead score, 1-10
minLeadScoreNoMinimum AI lead score, 1-10 (10 = hottest lead) — a different scale from the viability score
registeredToNoRegistered on/before this ISO date (YYYY-MM-DD)
growthSignalsNoAI growth signals: SUBSTANTIAL_CAPITAL, SOLID_CAPITALIZATION, MULTI_PERSON_TEAM, INTERNATIONAL_TEAM, TECHNOLOGY_ORIENTED, DIVERSIFIED_OFFERING, CONDITIONAL_CAPITAL_PROVISION, CAPITAL_BAND_FLEXIBILITY, IN_KIND_CONTRIBUTION, DETAILED_PURPOSE
registeredFromNoRegistered on/after this ISO date (YYYY-MM-DD)
capitalCurrencyNoCapital currency, e.g. "CHF" — capital bounds do not convert between currencies, so pair them with this
confidenceTiersNoAI confidence in its own analysis: HIGH, MEDIUM, LOW
analysisStatusesNoAnalysis states: NOT_ANALYSED, INCOMPLETE, ANALYSED
isMailboxCompanyNotrue keeps only companies whose registered purpose states no operating activity and whose setup corroborates it, false only those with an operating purpose; a company with no verdict matches neither
maxViabilityScoreNoMaximum AI viability score, 0-100
minViabilityScoreNoMinimum AI viability score, 0-100 — a different scale from the lead score
targetBuyerProfilesNoWho the AI thinks would sell to this company: B2B_SOFTWARE_VENDOR, PROFESSIONAL_SERVICES_FIRM, FINANCIAL_ADVISOR, REAL_ESTATE_AGENT, HR_RECRUITER, MARKETING_AGENCY, LOGISTICS_PROVIDER, INDUSTRY_SUPPLIER

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
sourceYes
disclaimerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safe read-only/idempotent profile, and the description goes well beyond them: rejection of unknown closed-set values and sub-3-char terms, empty-page semantics against a SHAB-only dataset, unscored companies sorting last, and cursor rejection when filters/sort change. These are exactly the operational traits an agent needs.

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

Conciseness4/5

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

The prose is dense and front-loaded, with the scoping semantics before the fallback pointers, and every sentence carries information. It is heavier than necessary — several clauses could be tightened — but there is little that is purely filler.

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

Completeness5/5

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

For a 32-parameter, zero-required search over a specialised dataset, the description covers filter semantics, empty-result interpretation, sorting caveats, and pagination constraints, and defers return-value detail to the existing output schema and to get_companies.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine conceptual meaning: purpose searches the register's own clause plus the English AI summary, language is not translated so terms must be passed in DE/FR/IT, and it warns that a score sort is not a substitute for the minimum filter. The lead-vs-viability scale distinction mostly duplicates the schema.

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

Purpose5/5

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

The description opens with a specific verb+resource and enumerates the searchable facets (name, canton, legal form, industry, location, registration date, capital, contact details, AI block). It explicitly differentiates itself from siblings by naming find_company_by_name (live register) and get_companies (full record/contact data).

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

Usage Guidelines5/5

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

It states when an empty page is a genuine zero versus when to fall back to find_company_by_name, explains that AI filters only match analysed companies and that analysisStatuses reports scope, and carves out purpose as the exception that reaches unanalysed companies. Alternatives and exclusions are explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources