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

Annotations already declare idempotentHint=true, readOnlyHint=true, and destructiveHint=false. The description adds that it returns 'full details' and 'download links', which are useful output traits. It does not contradict 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 sentences with no redundancy. The first sentence clearly states the purpose, and the second provides usage guidance. Every sentence 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 an output schema present, the description does not need to detail return values. It covers the tool's purpose and usage context sufficiently. Slight gap: what constitutes 'full details' could be elaborated, but the output schema handles that.

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 baseline is 3. The description adds value by clarifying that dataset_id must be obtained from seco_search_datasets first, which is beyond the schema description.

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 'Fetch' and the resource 'full details and download links for a specific SECO dataset'. It distinguishes this tool from siblings by specifying it should be used after seco_search_datasets, which retrieves a single dataset.

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?

Explicitly advises to use this tool after seco_search_datasets, providing clear context for when it should be invoked. This guidance helps the agent decide between this and sibling tools.

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 decken readOnly und destructive bereits ab; die Beschreibung ergänzt darüber hinaus nützliches Verhalten: nationale Aggregation, Jahresdurchschnitt ab 2000 und die Ablehnung des canton-Parameters statt stillschweigender nationaler Werte. Details zu Fehlermeldungen oder Authentifizierung fehlen, sind aber durch Annotationen und Schema teilweise abgedeckt.

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 klar strukturiert: Titelzeile, konzeptionelle Abgrenzung, technischer Geltungsbereich. Sie ist etwas länger als eine reine Funktionsbeschreibung, aber der konzeptionelle Absatz trägt zur Unterscheidung vom Geschwister-Tool bei. Die invokationsrelevanteste Aussage zur canton-Ablehnung steht erst am Ende.

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?

Da ein Output-Schema vorhanden ist und die Parameter im Schema vollständig beschrieben sind, muss die Beschreibung nur Verhalten und Kontext ergänzen. Das tut sie mit Quelle, Zeitraum, Aggregationsebene, nationaler Beschränkung und Parameter-Ablehnung. Ein Agent kann das Tool korrekt aufrufen und weiss, welche Anfragen abgelehnt werden.

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 beschreibt beide Parameter bereits vollständig, daher liegt die Basis bei 3. Die Beschreibung fügt echten Mehrwert hinzu, indem sie erklärt, warum canton abgelehnt wird und dass die Daten nur national verfügbar sind. response_format wird zwar nur im Schema erklärt, aber bei 100% Schema-Abdeckung ist das ausreichend.

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 macht deutlich, dass das Tool registrierte Stellensuchende (SECO/BFS) betrifft und grenzt diesen Begriff explizit von der Arbeitslosenkategorie ab. Auch der Verweis auf dieselbe Tabelle wie seco_get_unemployment_overview hilft bei der Einordnung, aber ein explizites Verb wie 'liefert' oder 'gibt zurück' fehlt.

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?

Der Text nennt die konkrete Einschränkung: Jahresdurchschnitte, national, keine kantonalen oder monatlichen Werte, und erklärt, dass ein übergebener canton-Parameter abgelehnt wird. Das grenzt die Nutzung klar vom Geschwister-Tool ab, auch wenn keine explizite 'benutze dies, wenn...'-Formulierung vorkommt.

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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that the tool also verifies availability (a behavioral trait beyond read-only URL generation), which provides useful context beyond the 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 concise sentences followed by a short paragraph. The main purpose is front-loaded in the first sentence. Every sentence adds value with no fluff.

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 tool's simplicity and the presence of an output schema (not shown but indicated), the description sufficiently explains the tool's function. It covers the purpose, the construction logic, and the verification step, making it complete for an agent to understand when and how to invoke it.

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 input schema has 100% description coverage with clear constraints (year range, month range, language pattern). The description adds the context that the tool constructs a URL for a specific month/year and verifies availability, going beyond the schema's parameter 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 description clearly states the tool generates and validates a URL for SECO's monthly labor market press report. It specifies the exact resource (monthly press report PDF URL) and verb (generate and validate), and is distinct from sibling tools that handle datasets or job seekers.

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 the tool is for constructing URLs for specific months/years and verifying availability, but it does not explicitly state when to use it versus sibling tools like seco_get_dataset or seco_get_unemployment_overview. No exclusionary guidance is provided.

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 indicate readOnlyHint=true and destructiveHint=false. Description adds context about being a leading indicator, but no additional behavioral traits beyond that.

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: first states function, second adds relevant context. No unnecessary words.

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 parameter set and presence of output schema, the description adequately covers what the tool does and its relevance.

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%, and description does not add new meaning to parameters. The single parameter 'response_format' is already described in schema.

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?

Description clearly states 'Get open job positions statistics from SECO/AMSTAT', specifying the verb and resource. It distinguishes from siblings like 'seco_get_job_seekers' and 'seco_get_unemployment_by_occupation'.

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?

Provides context for when to use the tool: for identifying professions/sectors in high demand for vocational guidance. While it doesn't explicitly exclude alternatives, the sibling tools cover different metrics.

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 declare readOnlyHint=true, destructiveHint=false. The description adds beyond this by explaining what specific statistics it returns (high unemployment rates, declining sectors, stable outcomes). 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 sentences: first directly states purpose, second adds context and use-case. No wasted words, every sentence 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?

Given the low complexity (one parameter, output schema exists, annotations present), the description is complete enough. It explains the purpose and relevance 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?

Schema description coverage is 100% with both parameters documented. The description does not add additional parameter semantics beyond what the schema provides, so 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 clearly states 'Get unemployment statistics broken down by occupation/profession'. It uses a specific verb and resource, and distinguishes itself from siblings by directly linking to Berufswahlberatung (career counseling) and listing specific insights it provides.

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 explicitly states that this tool is 'the most directly relevant tool for Berufswahlberatung' and gives examples of its use. It provides clear context but does not explicitly state when not to use it or provide alternatives.

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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely valuable behavior: a canton query is rejected with a refusal rather than a misleading national aggregate, and the tool outputs both SECO and ILO series labeled separately rather than mixing them. This contextualizes the data lineage (BFS publishes, SECO sources) beyond what structured fields convey.

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?

Front-loaded with the core purpose, then exclusions, then the ILO caveat. Well-organized with bold section breaks. Slightly long but every section earns its place given the rejection behavior and dual-series nuance; no filler.

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 an output schema present and the complex canton-refusal behavior fully explained, nothing an agent needs to call this correctly is missing. Covers source, scope, exclusions, and the labeling of the two series.

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% — all three params are documented in the schema. The description adds real value by reinforcing that canton is rejected outright and that year=None returns the latest available data, which clarifies the intent behind the nullable types beyond what the schema states.

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 precisely what it delivers: the annual series of registered unemployed (yearly average, 2000 to today) from BFS table T3.3.0.1. Explicitly differentiates from siblings by naming what it does NOT provide — monthly values and cantonal breakdowns — and flags the SECO-vs-ILO distinction, so an agent can separate it from seco_get_monthly_report_url and seco_get_youth_unemployment without opening schemas.

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 when-to-use context (annual national series) and explicit exclusions (monthly, cantonal — both get a refusal). Points to amstat.ch as the interactive fallback. It stops short of naming sibling tools like seco_get_monthly_report_url as direct alternatives, but the exclusion guidance is concrete and actionable.

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 establish the operation as read-only, idempotent, and non-destructive. The description adds a meaningful behavioral detail beyond the annotations: every response carries a totals check where parsed rows are summed and compared against the publication total. This gives the agent useful integrity context not present in the schema.

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 compact and front-loaded: scope first, then purpose/use case, then a behavioral guarantee. Every sentence earns its place, with no repetition of the title or redundant fluff.

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 input schema is highly detailed and an output schema is present, so the description rightly focuses on purpose, use case, and the totals-check behavior. There are no critical gaps for an agent to select and invoke this tool correctly.

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 description itself contains no parameter-specific guidance, but the input schema has 100% coverage with rich descriptions for noga, table, and response_format, including examples and grouping semantics. This meets the high-coverage baseline of 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?

The description names a specific resource — occupational accident and disease results per economic branch (NOGA 2008) — and states the analytical purpose: answering which branches carry which accident risk. The branch-level focus clearly separates it from overview and trend siblings, and the counterpart mention anchors it in vocational guidance.

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 a concrete use case: pair demand from seco_get_unemployment_by_occupation with occupational risk when making a Lehrberuf recommendation. It does not explicitly say when not to use it versus the other UGV tools, but the intended context is clear.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond the annotations by stating that the data is published by KSUV/SSUV c/o Suva rather than SECO, and by specifying the all-insurer, five-year scope. It does not disclose further operational behavior such as update cadence or data freshness.

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 sentences with no wasted words. The first sentence states what is returned, the second details scope and metrics, and the third adds source and positioning. Key information is front-loaded and every sentence 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?

Given that an output schema exists and annotations cover safety and idempotence, the description is largely complete for calling the tool correctly: it supplies the source, geographic scope, insurer coverage, time window, and relation to the server's unemployment tools. An explicit pointer to the UVG branch/trend sibling tools would improve completeness but is not essential.

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%, and the schema already fully documents the three parameters: years (with min, max, default), response_format (enum with default), and include_non_occupational (with default and explanatory note). The description adds no parameter-specific semantics beyond broad scope context, 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 clearly states that the tool returns Switzerland-wide key figures on occupational accidents and diseases, enumerates the specific metrics (registered/accepted cases, occupational diseases, pensions, fatalities, costs) and fixes the scope (22 insurers, five recent years). It does not explicitly distinguish itself from seco_get_uvg_by_branch or seco_get_uvg_trends, though the 'overview' and 'all 22 insurers' framing implies the difference.

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 gives clear context for when to use the tool: it complements the unemployment tools on the same server and covers the risk side of the labour market rather than the demand side. It does not explicitly state when not to use it or name alternatives such as the branch or trend UVG tools, stopping short of a full exclusion-based guideline.

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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds valuable behavioral context by disclosing that each data point carries a 'significant' flag and instructing to report significance only when that flag is set, which prevents misinterpretation. This goes beyond the annotations without contradicting them.

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 five sentences, front-loaded with the primary purpose ('Ten-year time series of accident indicators for one NOGA branch'), then the indicator list, then the significance caveat. Every sentence adds unique information; there is no fluff 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?

The combination of the description, comprehensive input schema (100% coverage), and annotations is sufficient for an agent to call the tool correctly and interpret results. The description explains data content and significance, the schema covers parameter syntax, and an output schema exists to define the return structure. Minor gaps like explicit usage guidance vs the annual table remain, but they are not essential 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 baseline is 3. The description does not add parameter-specific semantics beyond the schema; the schema already documents noga constraints, indicator matching behavior, branch_type meaning, and response_format. The description's mention of the twelve indicators and significance flag concerns output semantics, not parameter semantics.

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 tool provides a ten-year time series of accident indicators for one NOGA branch, and lists the indicators (e.g., case risk per 1000 full-time equivalents, occupational diseases, severe accidents). It does not explicitly name or contrast sibling tools such as seco_get_uvg_by_branch, so the differentiation is implied by the temporal scope rather than stated.

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 the tool is for time-series trend queries by branch, but it never explicitly says when to use this tool versus the annual table (seco_get_uvg_by_branch) or the overview. No exclusion criteria are given in the description text; the only relevant hint ('Ranges such as 41 - 42 exist only in the annual table') appears in the schema's noga field, not in the description.

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 read-only and non-destructive; the description adds meaningful behavior: no national dataset exists, count vs. quote are not interchangeable, and the tool labels the data and includes expert interpretation rather than merging figures. The only gap is unspecified behavior for unsupported or invalid canton codes, which is minor given the openWorldHint.

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 substantial but overlong, with a final paragraph about the previous version's example value that is irrelevant for tool selection or invocation. The key limitation is front-loaded, but several sentences repeat or editorialize rather than help an agent call the tool correctly.

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 thoroughly covers the data-availability situation and the difference between count and rate, but it leaves the actual invocation ambiguous: an agent cannot confidently determine how to request TG vs. ZG data, and the schema's contradictory canton description is not resolved. Since output schema exists, return-format details are covered, but the operational ambiguity is a significant gap.

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 description coverage is 100%, so the baseline is 3 even though the tool description adds little parameter-level detail. The description mentions TG and ZG but does not clarify how the canton parameter selects between them, especially since the schema itself says the canton code 'ändert am Ergebnis nichts' (changes nothing about the result).

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 the resource clearly: youth unemployment for ages 15–24 in Switzerland, with the caveat that no national series exists and only two cantons publish data. It also explains what the tool returns (the canton's own figure, labeled, plus seasonal/educational context). It does not explicitly compare itself to sibling tools, so it misses the top score.

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 tool is for youth-unemployment data in TG and ZG, and the description explicitly warns that national queries yield no numbers. However, it gives no concrete 'use this when...' guidance and names no alternatives among the sibling tools for national or general unemployment data.

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 declare readOnlyHint, destructiveHint, idempotentHint. The description adds that it returns a Markdown table with all 26 cantons, which is consistent and provides no surprises.

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 brief (3 sentences) and front-loaded with the main action. Every sentence adds value: what, why, and return format.

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 no parameters, rich annotations, and output schema (implied as Markdown table), the description fully covers what the agent needs to know. No gaps.

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?

No parameters exist, so schema coverage is 100%. The description adds value by specifying the exact output format (Markdown table) and the count (26 cantons). Baseline 4 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 clearly states 'List all Swiss canton codes and their names.' This is a specific verb+resource combination. It distinguishes itself from sibling tools like seco_get_dataset which query data, not codes.

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 explicitly says 'Utility tool to look up canton codes needed for other seco_* tools.' This tells the agent when to use it (to get codes for other tools) and implies it's not for querying data.

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?

The description goes beyond the readOnly/idempotent annotations by disclosing that the search is not SECO-filtered (contrary to what the tool name and title might imply), that the old filter targeted a non-existent organization and caused zero results, and that results include their publisher with different survey methodologies. This is significant behavioral context that prevents the agent from assuming the results are SECO official statistics.

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 verbose, spending several sentences on the historical 404 issue and the distinction between SECO and ILO statistics. While informative, it is not tightly front-loaded; the key usage fact (search over all datasets, results include publisher) could be conveyed in two sentences. It earns a middle score for offering useful detail at the cost of brevity.

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 search tool with an output schema and full parameter documentation, the description adequately covers the critical caveat that results come from various publishers and are not SECO-specific. It also explains potential empty-result scenarios. The only missing piece is explicit routing guidance to sibling tools, but the output schema likely covers return structure.

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 input schema already provides comprehensive descriptions for query, limit, and response_format (100% coverage), including examples and defaults. The description adds no parameter-specific semantics, so it relies on the schema, yielding baseline score.

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 'Sucht Arbeitsmarkt-Datensätze auf opendata.swiss', a specific verb+resource statement that clearly identifies a search tool over a public data catalog. It differentiates from siblings (seco_get_* specific indicators) by focusing on dataset discovery rather than retrieving a specific metric.

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 provides context that the search covers the entire opendata.swiss catalog, not just SECO, and explains the historical filtering that caused empty results. However, it does not explicitly tell the agent when to choose this search tool over the seco_get_* siblings, nor when not to use it; usage is implied rather than stated.

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