swissco_lei

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

Annotations already cover safety (readOnly, idempotent, openWorld), yet the description adds genuine domain behavior: GLEIF Level 2 records accounting consolidation, the listed parent is the accounting consolidator, that parent is frequently foreign and therefore absent from the Swiss register, and only ~28,000 of ~790,000 Swiss entities hold an LEI. This materially shapes how an agent should interpret results and empty responses.

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 and the mode-specific explanations earn their place. The verbatim column lists are the weakest part, since an output schema already exists and arguably documents those fields, but overall the structure is efficient and readable.

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 lookup with full schema coverage, three annotations, and an output schema, the description supplies exactly the missing pieces: the data model behind the L2 consolidation fields and the expectation that most entities have no LEI. Nothing essential for correct invocation is missing.

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 the baseline is 3, but the description adds real meaning: it spells out what each mode returns and clarifies that ``children`` switches from counting to listing consolidated entities. The exact fields per mode go beyond the terse schema 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 opening sentence names a specific resource (a company's LEI and its consolidation group) and the two modes are clearly described (single row vs. one row per consolidated child). It does not, however, contrast itself with any sibling tool (e.g. swissco_lookup, swissco_search), so the agent must infer when this is the right call.

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 is implied rather than stated: the description explains the semantics of the ``children`` mode and warns that 'an absent LEI is the normal case,' which primes correct interpretation of empty results. There is no explicit when-to-use/when-not or reference to alternative sibling tools for company data.

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