Firmenwatch — Swiss Company Register

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

Annotations already establish a safe read-only, idempotent, open-world operation. The description adds meaningful behavioral context beyond that: it distinguishes the newest publication from the verified boundary and instructs the agent to communicate the verified boundary to the user. 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 compact sentences with no filler. The first sentence states the output and distinction, and the second gives a clear usage directive. The most important guidance is front-loaded.

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

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

For a parameterless, read-only status tool, the description covers what it reports and when to use it, and the annotations cover safety and open-world semantics. It does not specify the exact response structure, but with no output schema the conceptual output is still described adequately.

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 tool has zero parameters, so the description cannot add parameter-level detail; per the baseline for 0-parameter tools this is sufficient. The empty schema is fully documented and nothing is left undocumented.

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 clear, specific action: it separates the newest available publication from the fully verified boundary and reports data-quality status. This makes the tool's role distinct from siblings like firma_suchen or uid_pruefen: it is about the reliability and currency of data, not about retrieving entity details.

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

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

It explicitly tells the agent when to invoke it: before relying on any answer ('Nutze dies, bevor du dich auf eine Auskunft verlässt'). It also instructs the agent to surface the verified boundary to the user. It does not name when-not-to-use or contrast with an alternative, so it stops short of a 5.

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

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

Beyond the readOnly/idempotent annotations, the description discloses important behavioral limitations: 'Der öffentliche KI-Zugang gibt keine Namen natürlicher Personen und keine Finanzschätzungen aus' and register capital is only returned 'mit belegter Währung'. This helps an agent set accurate expectations about response content.

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 front-loaded with the main action and then provides a compact, meaningful list of delivered data plus a key restriction. There is no filler; 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?

With no output schema, the description compensates by itemizing the response content: Stammdaten, Registerkapital, Personen- und Organabdeckung, Revision, Registerbefunde, Registerbezüge, and the latest Verlauf with official sources. It also states what is excluded, making the tool’s behavior sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so the UID format and the meaning of mit_verlauf are already documented in the input schema. The description adds no parameter-specific meaning beyond mentioning UID-based lookup and the latest history, 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 opens with a specific verb and resource: 'Liefert die öffentlichen Angaben zu einer Firma anhand der UID' and then enumerates the exact data categories returned. This makes the tool’s purpose clear and distinguishes it from related UID tools like firma_suchen, firma_risiko, and uid_pruefen.

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 usage is clear: use this tool when you have a UID and need a company's public register details, history, and related official data. It does not explicitly name alternatives or state when not to use it, but the UID-based scope provides a clear context.

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

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

Beyond the readOnly/idempotent annotations, the description adds meaningful behavioral context: the data source, the included finding types, the fact that each finding is individually named and dated, and the explicit non-evaluation of natural persons. 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?

Three sentences with no fluff: the action and scope are front-loaded, the relevant categories are enumerated, and the disclaimers are separated at the end. Every sentence contributes.

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 simple one-parameter schema and strong annotations, the description sufficiently covers source, scope, output granularity, and exclusions. It could be slightly more complete by describing empty/no-findings behavior, but for this tool the missing detail is minor.

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 only parameter, uid, is documented as 'UID der Firma'. The description adds no parameter-level detail, but none is needed because the schema fully covers the single input.

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 ('fasst zusammen') with a delimited resource ('was im Handelsamtsblatt zu einer Firma publiziert wurde und geschäftlich relevant ist') and lists concrete risk categories. It also explicitly distinguishes itself from a credit-rating tool, so an agent can tell it apart from sibling tools.

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 makes the intended use clear: retrieve business-relevant register findings for a company. It provides explicit exclusions ('KEINE Bonitätsauskunft', 'bewertet KEINE natürlichen Personen'), though it does not name sibling alternatives or spell out precise when-to-use versus when-not-to-use conditions relative to firma_details or bestand_status.

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

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

Die Annotationen deklarieren readOnlyHint=true, idempotentHint=true und destructiveHint=false, sodass die Sicherheits-/Nebenwirkungsaspekte abgedeckt sind. Die Beschreibung ergänzt nützliche Details zu Suchmethode und Rückgabefeldern, geht aber nicht auf Pagination, Sortierung oder weiteres Verhalten ein – das ist bei vorhandenen Annotationen akzeptabel.

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?

Die Beschreibung ist mit drei kurzen Sätzen sehr kompakt und front-loaded: Handlung, Ergebnis, Einsatzbedingung. Jeder Satz trägt zur Verständlichkeit bei, ohne Redundanz oder Füllwörter.

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?

Für ein Suchwerkzeug mit 4 Parametern, keinem Output-Schema und vollständigen Annotationen ist die Beschreibung ausreichend: Suchkriterien, Rückgabefelder und Nutzungskontext sind genannt. Kleinere Lücken wie Sortierreihenfolge oder Teiltreffer-Verhalten sind nicht kritisch für Auswahl und Aufruf.

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?

Das Schema hat 100% Parameterabdeckung: 'suchbegriff' erläutert den Suchbegriff samt UID-Format, 'anzahl' die Begrenzung, 'kanton' die erlaubten Kürzel, 'status' den Enum. Die Beschreibung fügt kaum etwas hinzu, was nicht schon im Schema steht; sie wiederholt lediglich den Namens-/UID-Suchmodus. Daher Baseline 3.

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?

Die Beschreibung nennt eine klare Aktion ('Sucht Firmen im Schweizer Handelsregister'), die Suchkriterien ('nach Name oder UID') und die gelieferten Felder. Der Satz 'Nutze dies, wenn die UID nicht bekannt ist' grenzt das Werkzeug von den Sibling-Tools ab, insbesondere von uid_pruefen und firma_details.

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

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

Die Beschreibung gibt eine explizite Einsatzbedingung: 'Nutze dies, wenn die UID nicht bekannt ist.' Das ist klare Kontextinformation, nennt jedoch keine konkreten Alternativ-Tools oder Ausschluss-Szenarien, daher 4 statt 5.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations, notably that it uses the 'jüngsten lückenlos verifizierten Publikationstag' and aggregates results by type, which clarifies data recency and ordering expectations.

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 sentences, each earning its place: what is returned, when to use it, and how to filter it. The most important information is front-loaded, and there is 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 tool with all optional parameters and no output schema, the description is sufficiently complete: it explains the return subject, aggregation, use cases, and filtering options. It could have mentioned the anzahl maximum explicitly, but the schema already carries that detail.

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 80%, so the schema already documents most parameters well. The description adds value by naming the three filter dimensions—Kanton, Meldungsart, and Stichwort—but it does not provide parameter-level details beyond what the schema offers.

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 deliverable: the latest fully verified publication day's structured company changes, counted by type. It is clearly differentiated from sibling tools like firma_suchen and firma_details by its briefing/aggregation purpose, though it does not explicitly name them.

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 explicitly lists when to use the tool: for a daily AI run, morning briefing, or automated market observation. It does not state exclusions or compare with alternatives, but the use cases are concrete enough to guide selection.

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

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

Annotations already mark the tool as read-only, idempotent, and open-world. The description adds useful behavior: it validates both format and Modulo 11 check digit, and it performs a registry lookup rather than only local validation. This is consistent with the annotations and provides extra context about what happens during the call.

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 core function is front-loaded and the usage guidance follows in a compact, actionable clause. Every sentence adds information.

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

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

For a one-parameter, read-only lookup tool, the description covers what it validates, that it checks the registry, and when to use it. The lack of an output schema means return details are not specified, but the simple scope and strong annotations make the description sufficient for correct selection and invocation.

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

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

The schema has 100% description coverage for the single required parameter ('Zu prüfende UID'), so the baseline is 3. The description adds that the UID is Swiss and subject to check-digit validation, but it does not specify accepted formats such as CHE prefix or separators, so it does not go beyond the schema baseline.

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 precise verb and object: 'Prüft eine Schweizer UID auf Format und Prüfziffer' and additionally says it looks the UID up in the registry ('schlägt sie im Bestand nach'). This is specific enough to distinguish uid_pruefen from siblings like firma_suchen or firma_details, which are about finding or retrieving company data.

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 gives an explicit trigger: 'Nutze dies, bevor du eine UID in ein System übernimmst — Tippfehler werden so erkannt.' This tells the agent when the tool should be used. It does not name alternatives or give explicit when-not-to-use conditions, so it falls just short of a 5.

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