swiss_company_by_uid

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

No annotations are provided, so the description carries the disclosure burden. It discloses the authentication requirement (ZEFIX credentials), which is useful behavioral context. However, it doesn't describe the response format, whether failed lookups return errors vs empty results, or any rate limits. For a single-UID read operation, this is adequate but not rich.

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, focused sentence that conveys purpose and a critical precondition in one line with zero wasted words. The UID format example is a useful concrete detail packed into the sentence efficiently.

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 single-parameter read tool, the description is fairly complete. However, the credential requirement is a meaningful operational detail worth expanding — e.g., what happens without ZEFIX credentials, or how setup relates to swiss_check_setup. The output schema is absent, so it does not clarify the return structure, but for a details lookup tool this is partially acceptable.

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 the uid parameter already documented in the schema with format instructions. The description reinforces the format but adds little new semantic meaning beyond what the schema provides. Baseline 3 is appropriate given full schema 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?

The description clearly states the verb ('Get') and specific resource ('full details of a Swiss company by its UID'), including a concrete UID format example (CHE-123.456.789). It distinguishes from the sibling swiss_company_search, which presumably searches rather than retrieves by exact identifier.

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 specifies 'by its UID' implying the tool is for exact-identifier lookup, which differentiates it from the sibling swiss_company_search. It also states the credential requirement ('Requires ZEFIX credentials'), telling the agent a precondition. However, it doesn't explicitly say 'use this when you have a UID' or contrast with alternatives like swiss_company_search.

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