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.