Semantic search across Swiss customs tariff (TARES) descriptions in French. Uses pre-computed Xenova/paraphrase-multilingual-mpnet-base-v2 embeddings (768d, FR) shipped with the TARES Pro bundle. Returns top-K HS8 codes by cosine similarity. Always inlines a non-official disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Embedding language (FR-only in v1) | fr |
| query | Yes | Free-text French description of a good | |
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the embedding model (Xenova/paraphrase-multilingual-mpnet-base-v2), dimension and language (768d, FR), the similarity metric (cosine), and a non-official disclaimer. It does not mention read-only behavior explicitly but semantic search is clearly a non-mutating operation.
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 three compact sentences, each serving a purpose: function/language, model context, and output/disclaimer. No filler or repetition, making it front-loaded and effective.
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?
The description covers the main functional aspects: scope, language, approach, and result type. It also mentions the mandatory disclaimer. However, it does not specify the exact response structure (e.g., whether similarity scores are included) or edge cases like empty results, which would be useful given no output schema.
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 covers query and lang with descriptions, but top_k lacks a schema description. The description's 'top-K' hints at the top_k parameter's role. With 67% schema coverage, the description partially compensates for the missing top_k description by connecting it to the output.
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 verb ('Semantic search'), a resource ('Swiss customs tariff (TARES) descriptions in French'), and the output ('top-K HS8 codes by cosine similarity'). This clearly distinguishes it from sibling tools like tariff_lookup (exact lookup) and classify_text (classification).
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 implies when to use it (free-text French queries for semantic matching) and the result type, providing clear context. However, it does not explicitly mention alternatives or when not to use it, such as preferring tariff_lookup for known HS8 codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
finma_search and kyc_check overlap heavily; both search the FINMA registry by name, and kyc_check essentially does what finma_search does with include_warnings=true. The other tools are distinct, but this pair creates real selection ambiguity.
Names mix verb-first (classify_text), noun-first (finma_search, tariff_lookup), and pure nouns (cross_walk, entity_history). All are lowercase with underscores, so it's readable, but the inconsistent verb placement breaks a predictable pattern.
9 tools is well-scoped for a server covering multiple Swiss data domains (classifications, FINMA, tariffs, statistics). Each tool serves a distinct purpose and earns its place without being overwhelming.
The set covers core workflows: text classification, code mapping, entity search/history, tariff lookup/changelog/search, and statistics. Minor gaps like a direct get-entity-by-UID endpoint or more granular statistics exist, but agents can work around them.
