Server Quality Checklist

Tool Scores

• export_multiple_datasetsB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions only the high-level action and outcome, without detailing side effects like directory creation, file overwriting, error handling, rate limits, or permissions. This is a significant gap for a write operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the action, scope, and output format. It is concise with no redundant information, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple batch export tool, and the presence of an output schema reduces the need to explain return values. However, it lacks details on operational behaviors (e.g., whether the output directory is created automatically) and does not differentiate from sibling tools, leaving some contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions already cover 100% of parameters (dataset_ids list, output_dir directory path). The description adds no additional parameter semantics beyond what the schema provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('export') and resource ('multiple Eurostat datasets'), and clearly states the output format (CSV files) and destination (target directory). This distinguishes it from sibling tools like export_to_csv, which likely handles single datasets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool instead of alternatives such as export_to_csv or query_dataset. It does not mention scenarios like handling batches, differences from single-export tools, or any prerequisites.

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

• describe_tableB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It clearly states the tool performs a read-only inspection and limits output to the first 5 rows, which is useful. However, it doesn't address potential errors or permission requirements, leaving some uncertainty.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately states the verb and object, with no filler. Every word contributes to the understanding of the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter and an output schema, the description covers the essential behavior and the table context. It could add edge cases like missing table behavior, but given the simplicity and the presence of an output schema, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the single parameter (table_name) with 100% coverage. The description adds the qualifier 'staged SQL table', reinforcing the parameter's domain, but no further semantic detail is provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Inspect') and names the resource ('schema and first 5 sample rows of a staged SQL table'), making the tool's function clear. It does not explicitly differentiate among siblings like query_dataset, but the focus on staged tables is distinctive.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided about when to use this tool versus sibling tools. The description implies it's for preliminary inspection but doesn't name alternatives or exclusions, so agents lack direction on tool selection.

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

• export_to_csvA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full behavioral burden. It mentions writing to a local CSV file, but does not disclose side effects like overwriting behavior, directory creation, or execution time. The word 'directly' adds some context but minimal detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no wasted words, front-loading the verb 'Export' and the resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple export tool, the description covers the core purpose, but lacks details on file handling behavior and relationship to similar tools. Annotations are absent and output schema exists but doesn't compensate for missing usage guidance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides complete descriptions for all three parameters with 100% coverage. The tool description does not elaborate on parameters beyond what the schema already states, so it adds no additional semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool exports a Eurostat dataset to a local CSV file, using a specific verb and resource. It distinguishes from siblings like export_multiple_datasets and download_dataset_to_sql by specifying a single dataset to CSV.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (exporting a single dataset to a local CSV) but does not explicitly mention alternatives or when not to use. Sibling tools like download_dataset_to_sql and export_multiple_datasets exist, but the description offers no guidance on choosing among them.

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

• list_popular_datasetsA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the curated nature and category filtering but does not explain behavior when category is omitted (e.g., returns all popular datasets), the meaning of 'high-value', ordering, pagination, or how categories are matched. This is a significant gap for an unannotated tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the action and resource. Every word contributes to the meaning without repetition or fluff, making it highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low-complexity with one optional parameter and an existing output schema, so the description needs less detail about return values. However, it lacks usage guidance and behavioral nuances (e.g., default listing when category is null), which an agent would need for confident invocation. It is minimally complete but leaves gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single optional parameter, so the baseline is 3. The description adds the phrase 'by category' but does not provide additional meaning beyond what the schema already specifies with example values. It does not compensate for any gaps because there are none in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and resource ('pre-curated high-value Eurostat datasets'), with the modifier 'by category' specifying the filtering dimension. This distinguishes it from sibling tools like search_datasets (which likely searches all datasets) and browse_themes (which browses by theme), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving curated high-value datasets, but does not explicitly state when to prefer this over alternatives or when not to use it. No alternatives are named, nor are exclusions given. The context is clear but not fully explicit.

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

• download_dataset_to_sqlA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description discloses the primary side effect (staging into an in-memory DuckDB table) but leaves out important behavioral details such as whether existing tables are overwritten, the effect of the optional filters on the 'complete dataset' claim, or potential download size/time implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence conveys the core action and destination with no redundant wording or filler. It is appropriately sized for the tool's straightforward purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema and output schema cover structural details, but for a tool with optional filters and possible overwrite behavior, the description omits critical operational caveats. It is complete enough for basic use but not fully robust for an agent needing to avoid surprising side effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds only high-level context ('complete', 'SQL table') without providing deeper parameter semantics like filter syntax or table naming rules beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description names a specific action ('Download'), a resource ('Eurostat dataset'), and a clear outcome ('stage it as a SQL table in the in-memory DuckDB canvas'). This clearly distinguishes it from sibling tools like search_datasets, query_dataset, or export_to_csv.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need a full Eurostat dataset staged for SQL querying, but it does not explicitly state when to use this versus query_dataset or get_dataset_info, nor does it mention exclusions or alternatives. Guidance is only implicit via the tool name and wording.

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

• query_datasetA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral disclosure burden. It mentions 'decode' but does not explain what that entails (e.g., converting codes to labels), nor does it mention read-only nature, return limits, pagination, or error behavior. This is insufficient for a query tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core purpose and key features (dimension filters, NUTS controls). It contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 7 parameters and an output schema, so the description needn't explain return values; however, it is terse about what 'decode' means and how this tool differs from similar siblings like download_dataset_to_sql. It provides basic context but lacks enough detail for a complex 7-param tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no parameter-level detail beyond what the schema already provides, though it hints at filters and NUTS controls which map to specific parameters. It does not elevate the meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool queries and decodes statistical observations from a Eurostat dataset, with specific mention of dimension filters and NUTS controls. This distinguishes it from sibling tools like search_datasets (searching for datasets) and get_dataset_info (metadata retrieval).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving observations with filtering, but does not explicitly state when to use this tool over siblings or mention alternatives. There is clear context but no exclusions or comparisons, so it earns a 4 per rubric.

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

• get_dataset_infoA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It explicitly lists what the tool returns ('metadata, dimension structures, time ranges, sample values') and the word 'Fetch' implies a read-only operation. It does not detail response format or pagination, but the output schema covers return structure, making this adequately transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that conveys the exact purpose without waste. Every word adds value and no extraneous details are included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one param) and has a full output schema, so the description need not explain return values. The description provides sufficient context for an agent to understand the tool's scope, though it could benefit from a hint about when to use it relative to siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single parameter with a clear description and examples (e.g., 'nama_10_gdp'). The description adds no parameter-specific information, so the baseline of 3 applies per the schema_description_coverage of 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and clearly identifies the resource ('metadata, dimension structures, time ranges, and sample values for a Eurostat dataset'). This distinguishes it from siblings like query_dataset (actual data) and get_dimension_values (specific dimension values).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this tool to get metadata and structure for a Eurostat dataset before querying data. However, there is no explicit guidance on when to prefer this over siblings like get_dimension_values or describe_table, nor any exclusions or alternative mentions.

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

• list_staged_tablesA
  4/5.0
  Behavior3/5

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

  The description indicates a read-only listing operation but does not disclose return format, pagination, or other behavioral details. Since no annotations are provided, it carries some burden, but the behavior is straightforward.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is concise, front-loaded, and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter list tool with an output schema, the description is mostly sufficient, though it could mention the intended use case or read-only nature to be fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the description need not elaborate. The schema is complete and vacuously covers all parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (list), the object (staged SQL tables), and the scope (DuckDB canvas), distinguishing it from sibling query and dataset tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage for discovering available staged tables before querying, but does not explicitly state when to use this vs alternatives like sql_query or describe_table.

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

• search_datasetsA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses cursor pagination as a behavioral trait, but does not explicitly state read-only behavior, rate limits, or other side effects. 'Search' implies read-only, but more detail would improve clarity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It efficiently captures the tool's purpose and pagination mechanism.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the presence of an output schema, and high schema coverage, the description is adequate. It could mention the return type or typical use cases, but the current level is sufficient for a straightforward search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions. The description adds minimal extra meaning beyond the schema, only contextualizing the cursor as part of pagination. Baseline 3 is appropriate when schema handles all parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('search') and resource ('Eurostat catalogue') with a clear scope ('by keyword with cursor pagination'). It distinguishes from siblings like browse_themes and list_popular_datasets by focusing on keyword search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies using this tool when you need to search the catalogue by keyword, which provides clear context. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it stops short of a 5.

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

• sql_queryA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states 'read-only' and 'SELECT', which implies mutation is not allowed, and notes that tables are 'staged in-memory', indicating data persistence/availability constraints. It does not cover error handling or SQL dialect limitations, but these are partially covered by the schema and output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the verb and scope. It contains no fluff and every word contributes to understanding the tool's purpose and constraints.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity, the description covers the essential context: read-only SQL execution against staged in-memory DuckDB tables. An output schema exists, so return values are handled separately. It could be more complete by explicitly listing prerequisites (e.g., tables must be staged) or limitations, but the phrase 'staged in-memory' implies this effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for the single 'query' parameter, including a concrete example. The description itself adds no extra parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Execute'), the specific operation ('read-only SQL SELECT query'), and the target resource ('staged in-memory DuckDB tables'). It distinguishes itself from sibling tools like query_dataset or get_dimension_values by specifying raw SQL execution against staged tables.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: it is for running SQL SELECT queries against staged DuckDB tables. However, it does not explicitly mention when to use it versus alternatives like query_dataset, nor does it state exclusions (e.g., non-SELECT queries or tables that are not staged). The context is clear but not explicit.

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

• get_dimension_valuesA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists all valid codes and labels and supports optional NUTS filtering. However, it does not mention edge cases such as behavior when nuts_level is supplied for a non-'geo' dimension, ordering, pagination, or error conditions. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the core action ('List all valid codes and labels'), followed by a concise optional modifier. Every word earns its place; there is no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with three parameters, full schema coverage, and an output schema present, the description is complete. It states the purpose, the resource targeted, and the optional filtering behavior. No additional context seems necessary for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond what the schema provides—the mention of NUTS filtering for 'geo' mirrors the schema's own parameter description. It gets the baseline score of 3 because it does not harm understanding but also does not add meaningful extra context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('List') and names the exact resource ('valid codes and labels for a specific dataset dimension'). It also mentions the optional NUTS regional filtering, which clearly distinguishes this tool from siblings like query_dataset or get_dataset_info. The function and scope are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the tool is for retrieving dimension code-label pairs and specifies when NUTS filtering can be applied (for 'geo'). It does not explicitly name alternatives or state exclusions, but the context is clear enough that an agent can infer when to use it. A slightly more explicit 'use this instead of get_dataset_info for dimension values' would push it to 5.

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

• browse_themesA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full disclosure burden. It explicitly states the output (categorized themes with key domain topics and dataset codes) and the scope ('top-level'), and the verb 'browse' implies a read-only operation. This is adequate for a simple, non-destructive tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short, purposeful sentences with a clear 'Returns:' label. It includes concrete examples and avoids any fluff or repetition. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given an output schema exists (per signal), the description does not need to detail return values exhaustively. It provides a high-level overview and examples that are sufficient for a simple browsing tool. The main gap is the lack of explicit guidance on when not to use it, but that is not critical here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description confirms that no input is required and provides context about what the output contains, which complements the empty input schema perfectly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'browse' with the resource 'top-level Eurostat themes' and provides concrete examples (Economy, Population, Trade, Environment, Industry). This clearly distinguishes it from sibling tools like search_datasets (searching) and get_dataset_info (specific dataset details).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this tool when you need to explore the top-level theme hierarchy of Eurostat data. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to decide when this tool is appropriate.

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